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FOREWORD 


Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management  of  the  Federal  Telecommunication 
Standards  Program  which  is  an  element  of  the  overall  GSA  Federal  Standard¬ 
ization  Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the 
Federal  Telecommunication  Standards  Committee,  identifies,  develops,  and  coor¬ 
dinates  proposed  Federal  Standards  which  either  contribute  to  the  interoper¬ 
ability  of  functionally  similar  Federal  telecommunication  systems  or  to  the 
achievement  of  a  compatible  and  efficient  interface  between  computer  and  tele¬ 
communication  systems.  In  developing  and  coordinating  these  standards  a  con¬ 
siderable  amount  of  effort  is  expended  in  initiating  and  pursuing  joint  stan¬ 
dards  development  efforts  with  appropriate  technical  committees  of  the 
Electronic  Industries  Association,  the  American  National  Standards  Institute, 
the  International  Organization  for  Standardization,  and  the  International 
Telegraph  and  Telephone  Consultative  Committee  of  the  International  Telecommu¬ 
nication  Union.  This  Technical  Information  Bulletin  presents  an  overview  of 
an  effort  which  is  contributing  to  the  development  of  compatible  Federal, 
national,  and  international  standards  in  the  area  of  data  communication  inter¬ 
face  standards.  It  has  been  prepared  to  inform  interested  Federal  activities 
of  the  progress  of  these  efforts.  Any  comments,  inputs,  or  statements  of 
requirements  which  could  assist  in  the  advancement  of  this  work  are  welcome 
and  should  be  addressed  to: 


Office  of  the  Manager 
National  Communications  System 
ATTN:  NCS-TS 
Washington,  D.C.  20305 
(202)  692-2124 
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BACKGROUND 


Intense  activity  over  the  past  several  years  is  leading  to  a  new  generation  of 
interface  standards  for  the  emerging  public  data  networks  being  implemented  in 
numerous  countries  around  the  world.  These  new  data  networks  will  offer  a 
variety  of  services  including  circuit-switched,  packet-switched,  and  leased 
line  to  support  the  rapidly  expanding  computer  and  digital  communications 
requirements. 

Packet-switching  technology  is  presently  dominating  current  implementations  as 
exemplified  by  Telenet  and  Tymnet  in  the  USA.  Active  implementations  are  also 
underway  in  Canada,  Japan,  and  many  European  countries. 

The  International  Telegraph  and  Telephone  Consultative  Committee  (CCITT)  has 
lead  the  way  in  early  standardization  of  interface  protocols  to  encourage 
timely  implementations  on  a  worldwide  basis.  In  early  1976,  the  draft  pro¬ 
posal  was  introduced  into  CCITT  for  a  virtual  circuit  packet-switched 
service.  Agreement  was  reached  in  May  1976,  and  in  September  1976,  the  pro¬ 
posal  was  approved  as  Recommendation  X.25  by  the  CCITT  Sixth  Plenary  Assembly. 

The  unprecedented  speed  at  which  X.25  was  adopted  left  serious  questions  as  to 
the  technical  soundness  of  the  standard.  There  were  many  uncompleted  items 
left  "for  further  study,"  and  there  were  numerous  ambiguities.  The  fact  that 
international  agreement  was  received,  however,  was  sufficient  for  a  number  of 
technologically  advanced  countries  to  make  large  investments  in  implementing 
new  public  data  networks  using  this  packet-switching  technology.  As  a  result, 
the  1976  version  X.25  proved  to  be  an  effective  guideline  for  the  new  genera¬ 
tion  of  designs. 

X.25  describes  the  interface  and  procedures  for  packet-switched  service  and  is 
defined  in  three  independent  architectural  levels  as  follows: 

Level  1  -  The  physical,  electrical,  functional,  and  procedural 

characteristics  to  activate,  maintain,  and  deactivate  the 
physical  link  between  the  DTE  and  the  DCE. 

Level  2  -  The  link  access  procedure  for  data  interchange  across  the  link 
between  the  DTE  and  the  DCE. 

Level  3  -  The  packet  format  and  control  procedures  for  the  exchange  of 
packets  containing  control  information  and  user  data  between  the 
DTE  and  DCE. 

Two  types  of  virtual  circuit  operation  were  originally  specified.  The  first 
is  virtual  call  service  which  establishes  and  end-to-end  connection  through 
the  packet  network.  This  connection  is  held  for  the  duration  of  the  communi¬ 
cation,  then  released.  The  other  is  permanent  virtual  circuit  service  which 
is  a  continuous  connection  between  two  users  through  a  packet  network.  These 
two  services  effectively  simulate  dialed  circuit-switched  connections  and 
leased  circuits,  respectively. 


Since  the  approval  of  X.25,  intense  work  has  continued  to  expand,  enhance,  and 
complete  the  basic  Recommendation  for  approval  at  the  CCITT  Seventh  Plenary 
Assembly  in  November  of  1980.  This  new  version  of  X.25  will  be  a  sound, 
established  standard  rather  than  a  design  guideline  as  it  was  initially.  The 
appendix  of  this  TIB  contains  the  complete  text  of  the  revised  X.25  which  is 
to  be  presented  for  approval  at  the  November  1980  Plenary  where  no  further 
technical  change  is  expected. 

Work  is  now  proceding  to  adopt  X.25  (1980)  as  a  joint  Federal  Telecommuni¬ 
cations  Standard  ( FED-STD ) - 1041 )  for  Telecommunication  Applications  and 
Federal  Information  Processing  Standard  (FIPS)  for  ADR  applications.  Publica¬ 
tion  is  expected  to  be  in  mid  1981.  In  the  meantime  due  to  a  large  demand  the 
application  of  X.25  by  Federal  agencies,  consideration  is  being  given  to  early 
publication  of  an  Interim  Federal  Standard  1041  in  November  1980  for  optional 
use. 


SUMMARY  OF  REVISIONS 


Physical  Level  -  The  text  was  greatly  clarified  to  specify  two  means  of  access 
-  dedicated  circuit  and  switched  circuit.  The  operating  conditions  applicable 
for  X.21  and  X.21  bis  are  more  fully  described  to  include  the  interface  signal 
conditions  and  the  provision  for  failure  detection  and  fault  isolation. 

Link  Level  -  Significant  changes  have  been  made  since  the  original  1976  ver¬ 
sion.  In  1978  a  provisional  revision  was  issued  specifying  a  new  procedure 
known  as  LAP-B  to  achieve  compatibility  with  the  ISO  HDLC  standards.  Subse¬ 
quently  LAP-B  was  further  refined  and  is  now  identified  as  the  preferred  pro¬ 
cedure  and  will  be  available  in  all  networks.  This  is  compatible  with  the 
HDLC  BA  class  of  procedures  with  options  2  and  8  (ANSI  X3.66  ADCCP  BA  Class, 
options  2,  8,  and  11). 

Packet  Level  -  A  number  of  significant  techical  and  editorial  enhancements 
were  made  for  this  level.  Many  technical  ambiguities  were  eliminated  and 
coding  of  the  many  fields  were  expanded  and  completed. 

More  importantly,  the  provisions  for  Datagram  service  were  added.  The  data¬ 
gram  operation  has  been  one  of  considerable  controversy  in  CCITT.  Determined 
efforts  from  the  USA,  however,  have  now  resulted  in  general  acceptance.  Data¬ 
grams  are  self-contained  packets  with  a  maximum  of  128  octets  of  user  data, 
and  each  datagram  has  sufficient  address  information  to  be  routed  to  its  des¬ 
tinations.  No  call  set-up  procedures  are  necessary.  Datagram  operations  more 
efficient  for  fast  transport  of  small  units  of  data  and  provides  greater  flex¬ 
ibility  for  a  number  of  network  and  user  applications.  At  this  time,  however, 
ther  are  no  known  public  data  network  implementating  of  Datagram  Service. 

Additionaly,  a  fast  select  facility  was  added  to  virtual  call  service.  The 
Fast  Select  provision  allows  a  full  128  octets  of  user  data  to  be  exchanged 
during  the  call  set-up  and  clearing  procedures  for  a  virtual  call.  Fast 
Select  also  greatly  Increases  the  efficiency  of  operation  for  many  transaction 
applications  and  will  be  Implemented  by  many  public  data  networks  for  this 
purpose. 


To  resolve  a  serious  incompatibility  among  some  of  the  early  X.25  implemen¬ 
tations,  a  new  procedure  was  added  to  dynamically  select,  on  a  per  data  packet 
basis  whether  acknowledgment  of  receipt  should  have  local  significance  or 
end-to-end  sigificance.  The  7t(1  bit  of  the  first  octet  of  data  packets  was 
designated  as  the  0  bit  for  delivery  confirmation.  If  D*0,  the  packet  is  only 
acknowledged  by  the  first  mode  of  the  network.  When  D*l,  the  packet  Is  not 
acknowledged  until  It  Is  received  and  acknowledged  by  the  destination  DTE. 

Additional  enhancements  of  particular  note  include  the  following: 

a.  Standard  values  which  apply  to  all  implementations  were  established  a 
maximum  data  field  size  of  12  octets,  a  window  size  of  2,  and  packet  sequence 
numbering  of  module  8.  Other  values  may  be  use  in  addition  as  options  either 
by  subscription  or  on  a  per  call  basis. 

b.  The  assignment  of  logical  channels  is  standardized. 

c.  The  number  of  optional  user  facilities  has  been  expanded  from  5  to 
29.  More  detailed  description  of  their  operation  has  also  been  included. 

d.  Bits  7  and  8  of  the  first  octet  of  the  Call  User  Data  field  of  call 
set-up  packet  have  been  standardized  to  indicate  possible  higher  level  pro¬ 
tocols. 

e.  The  state  diagrams  and  DCE  action  tables  have  been  reorganized  and 

enhanced  for  better  clarity  and  for  competeness. 

f.  The  signals  and  encoding  of  the  diagnostic  fields  were  added. 

g.  An  optional  DCF.  diagnostic  packet  was  added  to  assist  recovery  from 

some  error  conditions. 

h.  Logical  channel  0  was  reserved  for  Restart  and  Diagnostic  packets  only. 

i.  DCE  time-outs  and  DTE  time-limits  were  added  for  determing  error 

conditions. 

It  was  agreed  by  the  administrations  in  CCITT  that  all  networks  would  imple¬ 
ment  the  new  provisions  of  the  1980  version  of  X.25  by  January  1982.  Although 
there  were  some  significant  diferences  in  early  (pre  1980)  implementations  due 
to  ambiguities  and  incomplete  specifications,  X.25  has  now  envolved  to  be  a 
reasonably  complete  and  sound  standard  that  has  gained  significant  world-wide 
acceptance. 
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INTERFACE  BETWEEN  DATA  TERMINAL  EQUIPMENT  (DTE)  AND  DATA 
CIRCUIT-TERMINATING  EQUIPMENT  (DCE)  FOR  TERMINALS  OPERATING 
IN  THE  PACKET  MODE  ON  PUBLIC  DATA  NETWORKS 


The  establishment  in  various  countries  of  public  data  networks  providing 
packet-switching  data  transmission  services  creates  a  need  to  produce  standards 
to  facilitate  international  interworking. 


The  CCITT, 

considering 

a)  that  Recommendation  X.l  includes  specific  user  classes  of  service 
for  data  terminal  equipments  operating  in  the  packet  mode.  Recommendation  X.2 
defines  user  facilities,  Recommendations  X.21  and  X . 21  bis  define  DTE/DCE 
physical  level  interface  characteristics.  Recommendation  X.92  defines  the 
logical  control  links  for  packet-switching  data  transmission  services  and 
Recommendation  X.96  defines  call  progress  signals; 

b)  that  data  terminal  equipments  operating  in  the  packet  mode  will  send 
and  receive  network  control  information  in  the  form  of  packets; 

c)  that  certain  data  terminal  equipments  operating  in  the  packet  mode 
will  use  a  packet  interleaved  synchronous  data  circuit; 

d)  the  desirability  of  being  able  to  use  a  single  data  circuit  to  a 
DSE  for  all  user  facilities; 

e)  that  Recommendation  X.2  designates  virtual  call  and  permanent  virtual 
circuit  services  as  essential  (E)  services  to  be  provided  by  all  networks  and 
designates  datagram  service  as  an  additional  (A)  service  which  may  be  provided 
by  some  networks; 

f)  the  need  for  defining  an  international  recommendation  for  the  exchange 
between  DTE  and  DCE  of  control  information  for  the  use  of  packet-switching  data 
transmission  services; 

g)  that  the  necessary  elements  for  an  interface  recommendation  should  be 
defined  independently  as: 

Physical  Level  -  The  mechanical,  electrical,  functional  and  procedural 
characteristics  to  activate,  maintain  and  deactivate 
the  physical  link  between  the  DTE  and  the  DCE. 

Link  Level  -  The  link  access  procedure  for  data  interchange  across 
the  link  between  the  DTE  and  the  DCE. 
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tick- :t  Levs 1  -  The  packet  format  and  control  procedures  for  the  exchange 
of  packets  containing  control  information  and  user  data 
between  the  DTE  and  the  DCE. 

(unanimously)  di  dares  the  vi 

that  for  data  terminal  equipments  operating  in  the  packet  mode: 

1.  The  mechanical,  electrical,  functional  and  procedural  characteristics 
to  activate,  maintain,  and  deactivate  the  physical  link  between  the  DTE  and  the 
DCE  should  be  as  specified  in  1  bel  ow,  DTE/DCE  inter fa  »c  edr^-urir  rise. 

2.  The  link  access  procedure  for  data  interchange  eemss  the  link  between 
the  DTE  and  the  DCE  should  be  as  specified  in  2  below, Link  access  proc-  aur-. 
across  the  DTE /DCE  inter  fide.. 

3.  The  packet  level  procedures  for  the  exchange  of  control  information 
and  user  data  at  the  DTE/DCE  interface  should  be  as  specified  in  3  below. 

Description  of  the  packet  level  DTE/DCE  interface. 

4.  The  procedures  for  virtual  call  and  permanent  virtual  circuit 
services  should  be  as  specified  in  4  below.  Procedures  for  virtual  cin.cu.-it 
Services. 


5.  The  procedures  for  datagram  service  should  be  as  specified  in  5.  below 

Procedures  for  datagram,  service. 

6.  The  format  for  packets  exchanged  between  the  DTE  and  the  DCE  should 
be  as  specified  in  6  below,Packet  formats. 

7.  Procedures  and  formats  for  optional  user  facilities  should  be  as 
specified  in  7  below,  Procedures  and  formats  for  optional  user  facilities. 
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1 .  DTK /DCF  INTERFACE  CHARACTERISTICS  (PHYSICAL  LEVEL) 

The  DTE/DCE  physical  interface  character ist i cs  defined  as  the 
Physical  Level  element  shall  be  in  accordance  with  Recommendation 
X.21.  For  an  interim  period,  some  Administrations  or  RPOAs  may 
offer  a  DTE/DCE  interface  at  this  level  in  accordance  with  Recom¬ 
mendation  X.21  bis.  The  exact  use  of  the  relevant  sections  is 
detailed  below. 

1 • 1  The  Interface  Characteristics  for  a  DTE  Connected  to  a 

Packet  Switched  Data  Transmission  Service  by  a  PedjcaTed 
Circuit 


1.1.1  X.21 

1.1. 1.1  The  DTE/DCE  physical  interface  elements  shall  be  accord¬ 
ing  to  section  2  of  Recommendation  X.21. 

1.1. 1.2  The  operation  of  test  loops  shall  be  according  to  sec¬ 
tion  7  of  Recommendation  X.21. 

1.1. 1.3  The  procedures  for  entering  operational  phases  shall  t»e 
as  follows: 

a)  When  the  DTE  signals  c  »  ON,  signals  on  circuit  T  shall 
be  according  to  the  higher  level  procedures  described 
in  the  following  sections  of  this  Recommendation. 

b)  When  the  DCE  signals  i  «  ON,  signals  on  circuit  R  shall 
be  according  to  the  higher  level  procedures  described 
in  the  following  sections  of  this  Recommendation. 

c)  The  DTE/DCE  interface  should  normally  remain  in  the 
operational  condition  with  both  c  =  ON  and  i  «  ON  to 
enable  proper  operation  of  the  higher  level  procedures 
described  in  the  following  sections  of  this  Recommenda¬ 
tion  . 

d)  if  a  situation  necessitates  the  DTE  to  signal  DTE  ready 
or  DTE  uncontrolled  not  ready,  or  the  DCE  <•  o  signal  DCE 
ready  or  DCE  not  ready,  the  interface  should  reiurn  to 
the  operational  condition  with  both  c  ■  ON  and  i  *  ON 
when  the  situation  is  appropriate  to  enable  normal 
operation  of  higher  level  procedures  described  in  the 
following  sections  of  this  Recommendation. 

1.1.2  X.21  bis 

1.1.2. 1  The  DTE/DCE  physical  interface  elements  shall  be  accord¬ 
ing  to  section  1  of  Recommendation  X.21  bis. 


6 


1.1.2.?  Failure  detection  and  fault  isolation  shall  be  according 
to  section  3  of  Recommendation  X. 21  bis. 

1.1. 2. 3  When  circuits  10%  10%  107,  108  and  109  are  in  the  ON 
condition,  signals  on  circuits  103  and  104  shall  be  according  to 
the  higher  level  procedures  described  in  the  following  sections 
of  this  Recommendation. 

1 . 2  The  Interface  Characteristics  and  Procedures  for  a  DTE  Con¬ 
nected  to  a  Packet  Switched  Data  Transmission  Service 
through  a  Circuit  Switched  Data  Transmission  Service 


Note ;  The  full  interworking  regarding  the  user  facilities  and 
architectural  aspects  of  the  following  interface  charac¬ 
teristics  and  procedures  are  a  subject  of  further  study. 

1.2.1  X .  21 


1.2. 1.1  The  DTE/DCE  physical  interface  elements  shall  be  accord¬ 
ing  to  section  2  of  Recommendation  X.21.  The  procedures  for  cir¬ 
cuit  switched  access  shall  be  according  to  sections  3,  4,  5.1  and 
6  of  Recommendation  X.21. 

1.2. 1.2  The  operation  of  test  loops  shall  be  according  to  sec¬ 
tion  7  of  Recommendation  X.21. 

1.2. 1.3  When  c  *  ON  and  i  *  ON  (X.21  state  12  or  13),  signals  on 
circuits  T  and  R  shall  be  according  to  the  higher  level  pro¬ 
cedures  described  in  the  following  sections  of  this  Recommenda¬ 
tion. 

1.2.2  X.21  bis 


1.2. 2.1  The  DTE/DCE  physical  interface  elements  and  call  estab¬ 
lishment  procedures  shall  be  according  to  section  2  of  Recommen¬ 
dation  X.21  bis. 

1.2. 2. 2  Failure  detection  and  fault  isolation  shall  be  according 
to  section  3  of  Recommendation  X.21  bis. 

1.2. 2. 3  When  circuits  105,  106,  107,  108  and  109  are  in  the  ON 
condition,  signals  on  circuits  103  and  104  shall  be  according  to 
the  higher  level  procedures  described  in  the  following  sections 
of  this  Recommendation. 
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2.  LINK  ACCESS  PROCEDURE  ACROSS  THE  DTE/DCE  INTERFACE 


2. 1  Scope  and  Field  of  Application 

2.1.1  The  link  access  procedures  (LAP  and  LAPB)  are  described  as 
the  Link  Level  elements  and  are  used  for  data  interchange  between 
a  DCE  and  a  DTE  operating  in  user  classes  of  service  8  to  11  as 
indicated  in  Recommendation  X.l. 

2.1.2  The  procedures  use  the  principle  and  terminology  of  the 
High  Level  Data  Link  Control  (HDLC)  procedure  specified  by  the 
International  Organization  for  Standardization  (ISO). 

2.1.3  The  transmission  facility  is  duplex. 

2.1.4  DCE  compatibility  of  operation  with  the  ISO  balanced  class 
of  procedure  (Class  BA,  options  2,8)  is  achieved  using  the  provi¬ 
sions  found  under  the  headings  annotated  as  "applicable  to  LAPB" 
in  this  Recommendation. 

DTE  manufacturers  and  implementors  must  be  aware  that  the  pro¬ 
cedure  hereunder  described  as  LAPB  will  be  the  only  one  available 
in  all  networks. 

Likewise,  a  DTE  may  continue  to  use  the  provisions  found  under 
the  heading  annotated  as  "applicable  to  LAP"  in  this  Recommenda¬ 
tion  (in  those  networks  supporting  such  a  procedure),  but  for  new 
DTE  implementations,  LAPB  should  be  preferred. 


Note :  Other  possible  applications  for  further  study  are,  for 

example : 

-  two-way  alternate,  asynchronous  response  mode 

-  two-way  simultaneous,  normal  response  mode 

-  two-way  alternate,  normal  response  mode 
2. 2  Frame  Structure 

2.2.1  .\11  transmissions  are  in  frames  conforming  to  one  of  the 

formats  of  Table  2.1/X.25.  The  flag  preceding  the  address  field 
is  defined  as  the  opening  flag. 


TABLE  2.1/X.25  -  Frame  formats 


Bit 
order 
o  f 

trans¬ 
mission  12345*7P  1234567R  12345*78  lfi  to  1  1234eK7P 


Flag 

Address 

Control 

FCS 

Flag 

F 

01111110 

A 

P-bits 

c 

P-bits 

FCS 

l*-bi ts 

F 

01111110 

FCS*frame  checking  sequence 


Bit 

order 

of 

trans¬ 
mission  12345*7P  12345*78  12345*7R  16  to  1  12345*78 


Flag 

Address 

Control 

Information 

FCS 

Flag 

F 

01111110 

A 

8-bits 

C 

8-bits 

I 

N-bits 

FCS 

16-bits 

F 

01111110 

FCS*frame  checking  sequence 


2.2.2  Flag  Sequence 

All  frames  shall  start  and  end  with  the  flag  sequence  consisting 
of  one  0  followed  by  six  contiguous  Is  and  one  0.  A  single  flag 
may  be  used  as  both  the  closing  flag  for  one  frame  and  the  open¬ 
ing  flag  for  the  next  frame. 

2.2.3  Address  Field 

The  address  field  shall  consist  of  one  octet.  The  coding  of  the 
address  field  is  described  in  2.4.2  below. 
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2 . 2 . 4  Cont  rol  Field 

The  control  field  shall  consist  of  one  octet.  The  content  of 
th<s  field  is  described  in  2.3.2  below. 

Note :  The  use  of  the  extended  control  field  is  a  subject  for 

further  study. 

2.2.5  Information  Field 

The  information  field  of  a  frame  is  unrestricted  with  respect  to 
code  or  qroupinq  of  bits  except  for  the  packet  formats  specified 
in  3  below. 

See  2.3.4.10  and  2.4.11.3  below  with  reqard  to  the  maximum  infor¬ 
mation  field  length. 

2.2.fi  Transparency 

The  DTE  or  DCE,  when  transmitting,  shall  examine  the  frame  con¬ 
tent  between  the  two  flag  sequences  including  the  address,  con¬ 
trol,  information  and  TCS  sequences  and  shall  insert  a  0  bit 
after  all  sequences  of  5  contiguous  1  bits  (Including  the  last  5 
bits  of  the  FCS )  to  ensure  that  a  flag  sequence  is  not  simulated. 
The  DTE  or  DCE ,  when  receiving,  shall  examine  the  frame  content 
and  shall  discard  any  0  bit  which  directly  follows  5  contiguous  1 
bits . 


2.2.7  Frame  Checking  Sequence  (FCS ) 

Th*  FCS  shall  be  a  lfi-bit  sequence.  It  shall  be  the  ones  comple¬ 
ment  of  the  sum  (modulo  2)  of: 

1.  The  remainder  of  xk(xl5  +  xl4  ♦  x!3  +  ...  +  x2  +  x  ♦  1) 
divided  (modulo  2)  by  the  generator  polynomial 

xlfi  +  xl2  +  x5  +  1,  where  k  is  the  number  of  bits  in 
the  frame  existing  between,  but  not  including,  the 
final  bit  of  the  opening  flag  and  the  first  bit  of  the 
FCS,  excluding  bits  inserted  for  transparency,  and 

2.  the  remainder  after  multiplication  by  xlfi  and  then 
division  (modulo  2)  by  the  generator  polynomial 

xlfi  +  x 1 2  +  x5  +  1,  of  the  content  of  the  frame,  exist¬ 
ing  between  but  not  including,  the  final  bit  of  the 
opening  flag  and  the  first  bit  of  the  FCS,  excluding 
bits  inserted  for  transparency. 

As  a  typical  implementation,  at  the  transmitter,  the  initial 
remainder  of  the  division  is  preset  to  all  ones  and  is  then  modi¬ 
fied  by  division  by  the  generator  polynomial  (as  described  above) 
on  the  address,  control  and  information  fields;  the  ones  comple¬ 
ment  of  the  resulting  remainder  is  transmitted  as  the  lfi  bit  FCS 
sequence . 


1  0 


At  the  receiver  ,  the  initial  remainder  is  preset  to  all  ones,  and 
the  serial  incominq  protected  bits  and  the  FCS  when  divided  by 
the  generator  polynomial  will  result  in  a  remainder  of 
0001 1  1P1000P1 1  1 1  (  yl^  through  xO,  respectively)  in  the  absence 

of  transmission  errors. 

2 . 2 . P  Order  of  Pit  Transmission 

Addresses,  commands,  responses  and  sequence  numbers  shall  be 
transmitted  with  the  low  order  bit  first  (tor  example  the  first 
bit  of  the  sequence  number  that  is  transmitted  shall  have  the 
weight  2^ ) . 

The  order  of  transmitting  bits  within  the  information  field  is 
not  specified  under  2  of  this  Recommendation.  The  FCF  shall  be 
transmitted  to  the  line  commencing  with  the  coefficient  of  the 
highest  term. 


Notes  The  low  order  bit  is  defined  as  bit  1,  as  depicted  In 
Tables  2.1/X.25  to  2.4/X.25. 

2.2.9  Invalid  Frames 

A  frame  not  properly  bounded  by  two  flags,  or  having  fewer  than 
12  hits  between  flags,  is  an  invalid  frame. 

2.2.10  Frame  Abortl on 

Aborting  a  frame  is  performed  by  transmitting  at  least  seven  con¬ 
tiguous  Is  (with  no  inserted  Os). 

2.2.11  Interframe  Time  Fill 

Interframe  time  fill  is  accomplished  by  transmitting  contiguous 
flags  between  frames. 

2.2.12  Link  Channel  States 

2.2.12.1  Active  Channel  State 

A  channel  is  in  an  active  condition  when  the  DTE  or  DCE  is 
actively  transmitting  a  frame,  an  abortion  sequence  or  interframe 
time  fill . 

2.2.12.2  Idle  Channel  State 

A  channel  is  defined  to  be  In  an  idle  condition  when  a  contiguous 
Is  state  is  detected  that  persists  for  at  least  15  bit  times. 


Note  1>  The  action  to  be  taken  upon  detection  of  the  idle  chan¬ 
nel  state  is  a  subject  for  further  study. 


Note  2:  A  link  channel  as  defined  here  is  the  means  of  transmis¬ 
sion  for  one  direction. 

2. 3  Elements  of  Procedure 

2.3.1  The  elements  of  procedure  are  defined  in  terms  of  actions 
that  occur  on  receipt  of  commands  at  a  DTE  or  DCE. 

The  elements  of  procedure  specified  below  contain  a  selection  of 
commands  and  responses  relevant  to  the  link  and  system  configura¬ 
tion  described  in  2.1  above. 

A  procedure  is  derived  from  these  elements  of  procedure  and  is 
described  in  2.4  below.  Together  2.2  and  2.3  form  the  general 
requirements  for  the  proper  management  of  the  access  link. 

2.3.2  Control  Field  Formats  and  State  Variables 
2. 3. 2.1  Control  Field  Formats 

The  control  field  contains  a  command  or  a  response,  and  sequence 
numbers  where  applicable. 

Three  types  of  control  field  formats  (see  Table  2.2/X.25)  are 
used  to  perform  numbered  information  transfer  (I  frames),  num¬ 
bered  supervisory  functions  (S  frames)  and  unnumbered  control 
functions  (U  frames). 

TABLE  2.2/X.25  -  Control  field  formats 


Control 

field  bits 

1 

2 

3 

4 

5 

6  7  8 

I 

frame 

0 

N  (S) 

P/F 

N(R) 

S 

frame 

1 

0 

S 

S 

P/F 

N(R) 

U 

f  r  ame 

1 

1 

M 

M 

P/F 

M  M  M 

N  (S )  ■  transmitter  send  sequence  number  (bit  2  ■  low  order  bit) 
N(R)  ■  transmitter  receive  sequence  number  (bit  6  «  low  order  bit) 
S  *  supervisory  function  bit 

M  *  modifier  function  bit 

P/F  ■  poll  bit  when  issued  as  a  command,  final  bit  when 
issued  as  a  response  (1  •  Poll/Final) 


Information  transfer  format  -  I 


The  I  format  is  used  to  perform  an  information  transfer.  The 
functions  of  N(S),  N(R)  and  P/F  are  independent;  i.e.,  each  I 
frame  has  an  N(S),  an  N(R)  which  may  or  may  not  acknowledge  addi¬ 
tional  frames  received  by  the  DTF.  or  DCF,  and  a  P/F  bit. 

Supervisory  format  -  S 

The  S  format  is  used  to  perform  link  supervisory  control  func¬ 
tions  such  as  acknowledge  I  frames,  request  retransmission  of  I 
frames,  and  to  request  a  temporary  suspension  of  transmission  of 
T  frames. 

Unnumbered  format  -  U 


The  U  format  is  used  to  provide  additional  link  control  func¬ 
tions.  This  format  contains  no  sequence  numbers.  The  encoding 
of  the  unnumbered  commands  is  as  defined  in  Table  2.3/X.25. 

2. 3. 2. 2  Control  Field  Parameters 

Th«  various  parameters  associated  with  the  control  field  formats 
are  described  below. 

2 . 3 . 2 . 3  Modulus 

Each  I  frame  is  sequentially  numbered  and  may  have  the  value  0 
through  modulus  minus  one  (where  "modulus"  is  the  modulus  of  the 
sequence  numbers).  The  modulus  equals  8  and  the  sequence  numbers 
cycle  through  the  entire  range. 

2 . 3 . 2 . 4  Frame  Variables  and  Sequence  Numbers 
2.  3.  2.  4 , 1  Send  State  Variable  V(S) 

The  send  state  variable  denotes  the  sequence  number  of  the  next 
in-sequence  I  frame  to  be  transmitted.  The  send  state  variable 
can  take  on  the  value  0  through  modulus  minus  one.  The  value  of 
the  send  state  variable  is  incremented  by  one  with  each  succes¬ 
sive  I  frame  transmission,  but  at  the  DCE  cannot  exceed  N  (R )  of 
the  last  received  I  or  S  frame  by  more  than  the  maximum  number  of 
outstanding  I  frames  (k) .  The  value  of  k  is  defined  in  2.4.11.4 
below. 

2. 3. 2. 4. 2  Send  Sequence  Number  N(S) 

Only  1  frames  contain  N(S),  the  send  sequence  number  of  transmit¬ 
ted  frames.  Prior  to  transmission  of  an  in-sequence  I  frame,  the 
value  of  N (S )  is  updated  to  equal  the  value  of  the  send  state 
variable. 


■ 


( 
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2 .  3 .  2 .  4 ,  3  Receive  State  Variable  V(R) 

The  receive  state  variable  denotes  the  sequence  number  of  the 
next  in-sequence  I  frane  to  be  received.  This  receive  state 
variable  can  take  on  the  values  0  through  modulus  minus  one.  The 
value  of  the  receive  state  variable  is  incremented  by  the  receipt 
of  an  error  free,  in-sequence  I  frame  whose  send  sequence  number 
N  (S )  equals  the  receive  state  variable. 

2 . 3 , 2 . 4 . 4  Receive  Sequence  Number  N(R) 

All  I  frames  and  S  frames  contain  N{R),  the  expected  sequence 
number  of  the  next  received  I  frame.  Prior  to  transmission  of  a 
frame  of  the  above  types,  the  value  of  N(R)  is  updated  to  equal 
the  current  value  of  the  receive  state  variable.  N(R)  indicates 
that  the  DTE  or  DCE  transmitting  the  N(R)  has  correctly  received 
all  I  frames  numbered  up  to  and  including  N(R)  -  1. 

2. 3. 3  functions  of  the  Poll/Final  Bit 

The  poll/final  (P/F)  bit  serves  a  function  in  both  command  frames 
and  response  frames.  In  command  frames  the  P/F  bit  is  referred 
to  as  the  P  bit.  In  response  frames  it  is  referred  to  as  the  F 
bit. 

The  use  of  the  P/F  bit  is  described  in  2.4.3  below. 

2.3.4  Commands  and  Responses 

The  following  commands  and  responses  will  be  used  by  either  the 
DTE  or  DCE  and  are  represented  in  Table  2.3/X.25. 


1* 


TABLr  ?.?/X.25  -  Commands  and  responses 


12  ?  4  5  r,  7  f 


■ 

Format 

Command  s 

Response  s 

Encoding  | 

Information 

transfer 

T  (information) 

n 

N  (S) 

1 

N  (R)  ! 

» 

1 

Supervisory 

RR  (receive  ready) 

RNR  (receive 

not  ready) 

REJ  (reject) 

RR  (receive  ready) 

RNR  (receive 

not  ready) 

REJ  (reject) 

P/F 

P/F 

P/F 

N  (R  )  ! 

N  (R  ) 

N  (R) 

Unnumbered 

SARM  (set 

asynchronous 
response  mode) 

DM  (disconnected 
mode) 

1111 

P/F 

■ 

SARM  (set 

asynchronous 
balanced  mode) 

1111 

1 

1  0  0 

■  -  -  --  -  -  1 

DISC  (disconnect) 

110  0 

fl 

am 

UA  (unnumbered 

acknowl edge- 
ment) 

■ 

F 

1  1  0 

_ 1 

CMDR  (command 
reject) 

FRMR  (frame  reject) 

1110 

B 

n 

Note  JL  s  The  need  for,  and  use  of,  additional  commands  and 
responses  are  for  further  study. 


Note  2t  DTEs  do  not  have  to  implement  both  SARM  and  SABM;  furth¬ 
ermore  DM  and  SABM  need  not  be  used  if  SARM  only  is 
used . 

Note  2*  PR,  PNR  and  REJ  supervisory  command  frames  are  not  used 
by  the  DCE  when  SARM  is  used  (LAP). 
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The  commands  and  responses  are  as  follows: 

2. 3.4.1  Information  (I)  Command 

The  function  of  the  information  (I)  command  is  to  transfer  across 
a  data  link  sequentially  numbered  frames  containing  an  informa¬ 
tion  field. 

2.3.4.?  Receive  Ready  (RR)  Command  and  Response 

The  receive  ready  (RR)  supervisory  frame  is  used  by  the  DTE  or 
DCE  to: 

1)  indicate  it  is  ready  to  receive  an  I  frame; 

2)  acknowledge  previously  received  I  frames  numbered  up  to 
and  including  N(R)  -  1. 

RR  may  be  used  to  clear  a  busy  condition  that  was  initiated  by 
the  transmission  of  RNR.  The  RR  command  with  the  P  bit  set  to  1 
may  be  used  by  the  DTE  or  DCE  to  ask  for  the  status  of  the  DCE, 
or  DTE,  respectively. 

2. 3. 4. 3  Reject  (REJ)  Command  and  Response 

The  reject  (REJ)  supervisory  frame  is  used  by  the  DTE  or  DCE  to 
request  retransmission  of  I  frames  starting  with  the  frame  num¬ 
bered  N  (R ) ,  I  frames  numbered  N(R)  -  1  and  below  are  ack¬ 
nowledged.  Additional  I  frames  pending  initial  transmission  may 
be  transmitted  following  the  retransmitted  I  frame(s). 

Only  one  REJ  exception  condition  for  a  given  direction  of  infor¬ 
mation  transfer  may  be  established  at  any  time.  The  REJ  excep¬ 
tion  condition  is  cleared  (reset)  upon  the  receipt  of  an  I  frame 
with  an  N  (S )  equal  to  the  N(R)  of  the  REJ.  The  REJ  command  with 
the  P  bit  set  to  1  may  be  used  by  the  DTE  or  DCE  to  ask  for  the 
status  of  the  DCE  or  DTE,  respectively. 

2. 3. 4. 4  Receive  Not  Ready  (RNR)  Command  and  Respond 

The  receive  not  ready  (RNR)  supervisory  frame  is  used  by  the  DTE 
or  DCE  to  indicate  a  busy  condition;  i.e.,  temporary  inability  to 
accept  additional  incoming  I  frames.  I  frames  numbered  up  to  and 
including  N(R)  -  1  are  acknowledged.  I  frame  N(R)  and  subsequent 
I  frames  received,  if  any,  are  not  acknowledged;  the  acceptance 
status  of  these  I  frames  will  be  indicated  in  subsequent 
exchanges . 

An  indication  that  the  busy  condition  has  cleared  is  communicated 
by  the  transmission  of  a  UA,  RR,  REJ  or  SABM.  The  RNR  command 
with  the  P  bit  set  to  1  may  be  used  by  the  DTE  or  DCE  to  ask  for 
the  status  of  the  DCE  or  DTE,  respectively. 
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2.  3.  4.5  Set  Asynchronous  Rpsponse  Mode  (SARK)  Comnanr3 

The  SARM  unnumbered  command  is  used  to  place  the  addressed  DTP  or 
DCE  in  the  asynchronous  response  mode  (ARM)  information  transfer 
phase  . 

No  information  field  is  permitted  with  the  SARM  command.  A  PTE 
or  DCE  confirms  acceptance  of  SARM  by  the  transmission  at  the 
first  opportunity  of  a  UA  response.  Upon  acceptance  of  this  com¬ 
mand  the  DTE  or  DCE  receive  state  variable  V(R)  is  set  to  0. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this 
command  is  actioned  remain  unacknowledged. 

2.3.4. R  Set  Asynchronous  Balanced  Mode  (SABM)  Command 

The  SABM  unnumbered  command  is  used  to  place  the  addressed  DTE  or 
DCE  in  the  asynchronous  balanced  mode  (ABM)  information  transfer 
phase . 

No  information  field  is  permitted  with  the  SABM  command.  A  DTE 
or  DCE  confirms  acceptance  of  SABM  by  the  transmission  at  the 
first  opportunity  of  a  UA  response.  Upon  acceptance  of  this  com¬ 
mand  the  DTE  or  DCE  send  state  variable  V(S)  and  receive  state 
variable  V(R)  are  set  to  n. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this 
command  is  actioned  remain  unacknowledged. 

2. 3. 4. 7  Disconnect  (DISC)  Command 

The  DISC  unnumbered  command  is  used  to  terminate  the  mode  previ¬ 
ously  set.  It  is  used  to  inform  the  DTE  or  DCE  receiving  the 
DISC  that  the  DTE  or  DCE  sending  the  DISC  is  suspending  opera¬ 
tion,  No  information  field  is  permitted  with  the  DISC  command. 
Prior  to  actioning  the  command,  the  DTE  or  DCE  receiving  the  DISC 
confirms  the  acceptance  of  DISC  by  the  transmission  of  a  UA 
response.  The  DTE  or  DCE  sending  the  DISC  enters  the  discon¬ 
nected  phase  when  it  receives  the  acknowledging  UA  response. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this 
command  is  actioned  remain  unacknowledged. 

2. 3. 4.8  Unnumbered  Acknowledge  (UA)  Response 

The  UA  unnumbered  response  is  used  by  the  DTE  or  DCE  to  ack¬ 
nowledge  the  receipt  and  acceptance  of  the  U  format  commands. 
Received  U  format  commands  are  not  actioned  until  the  UA  response 
i s  transmitted.  The  UA  response  is  transmitted  as  directed  by 
the  received  U  format  command.  No  information  field  is  permitted 
with  the  UA  response. 
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2. 3. 4. 9  Disconnected  Mode  (DM)  Response 

The  DM  response  is  used  to  report  a  status  where  the  DTE  or  DCE 
is  logically  disconnected  from  the  link,  and  is  in  the  discon¬ 
nected  phase.  The  DM  response  is  sent  in  this  phase  to  reauest  a 
set  mode  command,  or,  if  sent  in  response  to  the  reception  of  a 
set  mode  command,  to  inform  the  DTE  or  DCE  that  the  DCE  or  DTE, 
respectively,  is  still  in  disconnected  phase  and  cannot  action 
the  set  mode  command.  No  information  field  is  permitted  with  the 
DM  response. 

A  DTE  or  DCE  in  a  disconnected  phase  will  monitor  received  com¬ 
mands,  and  will  react  to  SABM  as  outlined  in  2.4.5  below  and  will 
respond  DM  to  any  other  command  received  with  the  P  bit  set  to  1. 

2.3.4.10  Command  Reject  (CMDR )  Response 
Frame  Reject  (FRMR)  Response 

The  CMDR  (FRMR)  response  is  used  by  the  DTE  or  DCE  to  report  an 
error  condition  not  recoverable  by  retransmission  of  the  identi¬ 
cal  frame;  i.e.,  one  of  the  following  conditions,  which  results 
from  the  receipt  of  a  frame  without  FCS  error: 

1.  the  receipt  of  a  command  or  response  that  is  invalid  or 
not  implemented; 

2.  the  receipt  of  an  I  frame  with  an  information  field 
which  exceeds  the  maximum  established  length; 

3.  the  receipt  of  an  invalid  N (R ) .  (In  the  case  of  LAP, 
see  2. 4. 8. 1 ) 

4.  the  receipt  of  a  frame  with  an  information  field  which 
is  not  permitted  or  the  receipt  of  an  S  or  U  frame  with 
incorrect  length. 

An  invalid  N  (R )  is  defined  as  one  which  points  to  an  I  frame 
which  has  previously  been  transmitted  and  acknowledged  or  to  an  I 
frame  which  has  not  been  transmitted  and  is  not  the  next  sequen¬ 
tial  I  frame  pending  transmission. 

An  information  field  which  immediately  follows  the  control  field, 
and  consists  of  3  octets,  is  returned  with  this  response  and  pro¬ 
vides  the  reason  for  the  CMDR  (FRMR)  response.  This  format  is 
given  in  Table  2.4/X.25. 


-  IP  - 

TABLE  "'.4/X.25  -  CMDR  (FRMR)  information  field  format 

Information  field  bits 


1  2  3  4  5 

5  7  8 

9 

10  11  13 

1  3 

14  15  15 

17 

IP 

19 

20 

21 

2? 

23 

2<3 

Re  j  ected 
control 

frame 

field 

0 

V  (R) 

see  Note 

V  (R) 

W 

X 

Y 

Z 

0 

0 

0 

0 

-  Rejected  frame  control  field  is  the  control  field  of  the 
received  frame  which  caused  the  command  (frame)  reject. 

-  V  (S )  is  the  current  send  state  variable  value  at  the  DTE  or 
DCE  reporting  the  rejection  condition  (bit  10  =  low  order 
bit). 

-  V  (R )  is  the  current  receive  state  variable  value  at  the  DTE 
or  DCE  reporting  the  rejection  condition  (bit  14  *  low  order 
bit)  . 

-  W  set  to  1  indicates  that  the  control  field  received  and 
returned  in  bits  1  through  8  was  invalid  or  not  implemented. 

-  X  set  to  1  indicates  that  the  control  field  received  and 
returned  in  bits  1  through  8  was  considered  invalid  because 
the  frame  contained  an  information  field  which  is  not  per¬ 
mitted  or  is  an  S  or  U  frame  with  incorrect  length.  Bit  W 
must  be  set  to  1  in  conjunction  with  this  bit. 

-  Y  set  to  1  indicates  that  the  information  field  received 
exceeded  the  maximum  established  capacity  of  the  DTE  or  DCE 
reporting  the  rejection  condition. 

-  Z  set  to  1  indicates  that  the  control  field  received  and 
returned  in  bits  1  through  8  contained  an  invalid  N(R). 

Note:  Bits  9,  13,  21  to  24  shall  be  set  to  0  for  CM DR.  For 

FRMR,  bits  9,  21  to  24  shall  be  set  to  0.  Bit  13  shall  be 
set  to  1  if  the  frame  rejected  was  a  response,  and  set  to 
o  if  the  frame  rejected  was  a  command. 


19 


2.3.5  Exception  Condition  Reporting  and  Recovery 

The  error  recovery  procedures  which  are  available  to  effect 
recovery  followinq  the  detection/occur rence  of  an  exception  con¬ 
dition  at  the  link  level  are  described  below.  Exception  condi¬ 
tions  described  are  those  situations  which  may  occur  as  the 
result  of  transmission  errors,  DTE  or  DCE  malfunction  or  opera¬ 
tional  situations. 

2. 3. 5.1  Busy  Condition 

The  busy  condition  results  when  a  DTE  or  DCE  is  temporarily 
unable  to  continue  to  receive  I  frames  due  to  internal  con¬ 
straints,  e.g.,  receive  buffering  limitations.  In  this  case  an 
RNR  frame  is  transmitted  from  the  busy  DCE  or  DTE.  I  frames 
pending  transmission  may  be  transmitted  from  the  busy  DTE  or  DCE 
prior  to  or  following  the  RNR.  Clearing  of  the  busy  condition  is 
indicated  as  described  in  2. 3. 4. 4  above. 

2. 3. 5. 2  N  (S  )  Sequence  Error 

The  information  field  of  all  I  frames  whose  N(S)  does  not  equal 
the  receive  state  variable  V(R)  will  be  discarded. 

An  N(S)  sequence  exception  condition  occurs  in  the  receiver  when 
an  I  frame  received  error-free  (no  FCS  error)  contains  an  N(S) 
which  is  not  equal  to  the  receive  state  variable  at  the  receiver. 
The  receiver  does  not  acknowledge  (increment  its  receive  state 
variable)  the  I  frame  causing  the  sequence  error,  or  any  I  frame 
which  may  follow,  until  an  I  frame  with  the  correct  N(S)  is 
received . 

A  DTE  or  DCE  which  receives  one  or  more  I  frames  having  sequence 
errors  but  otherwise  error-free  shall  accept  the  control  informa¬ 
tion  contained  in  the  N(R)  field  and  the  P  bit  to  perform  link 
control  functions;  e.g.,  to  receive  acknowledgement  of  previously 
transmitted  I  frames  and  to  cause  the  DTE  or  DCE  to  respond  (P 
bit  set  to  1).  Therefore,  the  retransmitted  I  frame  may  contain 
an  *>■  (R )  field  and  P  bit  that  are  updated  from,  and  therefore  dif¬ 
ferent  from,  the  ones  contained  in  the  originally  1 1 m  ?  tted  I 
f  r ame . 

2. 3. 5. 3  REJ  Recovery 

The  REJ  is  used  to  initiate  an  exception  recovery  (retransmis¬ 
sion)  following  the  detection  of  a  sequence  error. 

Only  one  "sent  REJ"  exception  condition  from  a  DTE  or  DCE  is 
established  at  a  time.  A  sent  REJ  exception  condition  is  cleared 
when  the  requested  1  frame  is  received. 

A  DTE  or  DCE  receiving  REJ  initiates  sequential  ( re- ) transmission 
of  I  frames  starting  with  the  I  frame  indicated  by  the  N(R) 


2  n 


obtained  in  the  REJ  frame. 

2.  3. 5. 4  Time-out  Recovery 

If  a  DTE  or  DCF,  due  to  a  transmission  error,  does  not  receive 
(or  receives  and  discards)  a  single  I  frame  or  the  last  I  frame 
in  a  sequence  of  T  frames,  it  will  not  detect  an  out-of-sequence 
exception  condition  and  therefore  will  not  transmit  REJ.  The  DTE 
or  DCE  which  transmitted  the  unacknowledged  I  frame(s)  shall, 
followina  the  completion  of  a  system  specified  time-out  period 
(see  2.4.11.1  below),  take  appropriate  recovery  action  to  deter¬ 
mine  at  which  I  frame  retransmission  must  begin. 

2. 3. 5. 5  FCS  Error  and  Invalid  Frame 

Any  frame  received  with  an  FCS  error  or  which  is  invalid  (see 
2.2.9  above)  will  be  discarded  and  no  action  is  taken  as  the 
result  of  that  frame. 

2.3.5.fi  Rejection  Condition 

A  rejection  condition  is  established  upon  the  receipt  of  an  error 
free  frame  which  contains  an  invalid  command/response  in  the  con¬ 
trol  field,  an  invalid  frame  format,  an  invalid  N  (R )  (however  see 
2.4.8.  1  below  for  LAP  application)  or  an  information  field  which 
exceeds  the  maximum  information  field  length  which  can  be  accom- 
mod  ated  . 

At  the  DTE  or  DCE,  this  exception  is  reported  by  a  CM DR  (FRMR ) 
response  for  appropriate  DCE  or  DTE  action,  respectively.  Once  a 
DCE  has  established  a  CM DR  (FRMR)  exception,  no  additional  I 
frames  are  accepted,  until  the  condition  is  reset  by  the  DTE, 
except  for  examination  of  the  P  bit  (LAPB)  or  examination  of  the 
P  bit  and  N(R)  (LAP).  The  CM DR  (FRMR)  response  may  be  repeated 
at  each  opportunity  until  recovery  is  effected  by  the  DTE,  or 
until  the  DCE  initiates  its  own  recovery. 

2. 4  Description  of  the  Procedure 

2.4.1  Procedure  to  Set  the  Mode  Variable  B  (Applicable  if  Both 
LAP  and  LAPB  are  Implemented) 

The  DCE  will  maintain  an  internal  mode  variable  B,  which  it  will 
set  as  follows: 

-  to  1 ,  upon  acceptance  of  an  SABM  command  from  the  DTE 

-  to  0 ,  upon  acceptance  of  an  SARM  command  from  the  DTE. 

Changes  to  the  mode  variable  B  by  the  DTE  should  occur  only  when 
the  link  has  been  disconnected  as  described  in  2. 4. 4.  3  or  2. 4.5. 3 
below. 
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Should  a  DCE  malfunction  occur,  the  internal  mode  variable  P  will 
upon  restoration  of  operation,  but  prior  to  link  set-up  by  the 
DTE,  be  initially  set  to  1. 

Whenever  F  is  1,  the  DCE  will  use  the  LAPB  link  set-up  and 
disconnection  procedure  and  is  said  to  be  in  the  LAPB  (balanced) 
mode , 

Whenever  B  is  0,  the  DCE  will  use  the  LAP  link  set-up  and  discon¬ 
nection  procedure,  and  is  said  to  be  in  the  LAP  mode. 

The  following  are  applicable  to  both  LAP  and  LAPB  modes:  2,4.2, 
2.4.3,  2.  4,6,  2.4.11. 


The  following  are  applicable  only  to  the  LAP  mode:  2.4.4,  2.4.7, 

?  4  t> 

The  following  are  applicable  only  to  the  LAPB  mode:  2.4.5,  2,4.9, 
2.4.10. 

2.4.2  Procedure  for  Addressing  (Applicable  to  Both  LAP  and  LAPB) 

Frames  containing  commands  transferred  from  the  DCE  to  the  DTE 
will  contain  the  address  A. 

Frames  containing  responses  transferred  from  the  DTE  to  the  DCE 
shall  contain  the  address  A. 

Frames  containing  commands  transferred  from  the  DTE  to  the  DCE 
shall  contain  the  address  B. 

Frames  containing  responses  transferred  from  the  DCE  to  the  DTE 
will  contain  the  address  B. 

A  and  B  addresses  are  coded  as  follows: 

Address  1  2  3  4  5  6  7  p 

A  1  1  0  0  0  0  0  0 

b  inoonooo 

Note:  The  DCE  will  discard  all  frames  receive  with  an  address 

other  than  A  or  B;  the  DTE  should  do  the  same, 

2.4.3  Procedure  for  the  Use  of  the  P/F  Bit  (Applicable  to  Both 
LAP  and  LAPB) 

The  DTE  or  DCE  receiving  a  RAR*I,  SABM,  DISC,  supervisory  command 
or  an  I  frame  with  the  P  bit  set  to  1,  will  set  the  F  bit  to  1  in 
the  next  response  frame  it  transmits. 
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The  response  frame  returned  by  the  DrE  to  a  FARM,  SABM  or  DTSr‘ 
command  with  the  P  bit  set  to  1  will  be  a  UA  (or  DM)  response 
with  the  F  bit  set  to  1.  The  response  frame  returned  by  the  DCF 
to  I  frame  with  the  P  bit  set  to  1  will  be  an  RR,  REJ  or  RN’R 
or  cm DR  or  FRMR  response  format  with  the  F  bit  set  to  1. 

The  response  frame  returned  by  the  DCE  to  a  supervisory  command 
frame  with  the  P  bit  set  to  1  will  be  an  RR,  RNR  or  CMDR  or  FRMR 
response  with  the  F  bit  set  to  1. 

The  P  bit  may  be  used  by  the  DCF  in  conjunction  with  the  timer 
recovery  condition  (see  2.4.R.8  below). 

Note  Other  use  of  the  P  bit  by  the  DCE  is  a  subject  for  further 
study. 

2.4.4  Procedure  for  Link  Set-up  and  Disconnection  (Applicable  to 
LAP) 

2 . 4 . 4 . 1  Link  Set-up 

The  DCE  will  indicate  that  it  is  able  to  set  up  the  link  by 
transmitting  contiguous  flags  (active  channel  state). 

The  DTE  shall  indicate  a  request  for  setting  up  the  link  by 
transmitting  a  SARM  command  to  the  DCE. 

Whenever  receiving  a  SARM  command,  the  DCE  will  return  a  UA 
response  to  the  DTE  and  set  its  receive  state  variable  V(R)  to  0. 

Should  the  DCE  wish  to  indicate  a  request  for  setting  up  the 
link,  or  after  transmission  of  a  UA  response  to  a  first  SARM  com¬ 
mand  from  the  DTE  as  a  request  for  setting  up  the  link,  the  DCE 
will  transmit  a  SARM  command  to  the  DTE  and  start  Timer  T1  (see 

2.4.11.1  below).  The  DTE  will  confirm  the  reception  of  the  SARM 
command  by  transmitting  a  UA  response. 

When  receiving  the  UA  response  the  DCE  will  set  its  send  state 
variable  to  n  and  stop  its  Timer  Tl.  If  Timer  T1  runs  out  before 
the  UA  response  is  received  by  the  DCE,  the  DCE  will  retransmit  a 
SARM  command  and  restart  Timer  Tl. 

After  transmission  of  SARM  N2  times  by  the  DCE,  appropriate 
recovery  action  will  be  initiated. 

The  value  of  N2  is  defined  in  2.4.11.2  below. 

2. 4. 4. 2  Information  Transfer  Phase 

After  having  both  received  a  UA  response  to  a  SARM  command 
transmitted  to  the  DTE  and  transmitted  a  UA  response  to  a  SARM 
command  received  from  the  DTE,  the  DCE  will  accept  and  transmit  I 
and  S  frames  according  to  the  procedures  described  in  2.4.R 
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bel ow. 

When  receiving  a  SARM  command,  the  DCE  will  conform  to  the  reset¬ 
ting  procedure  described  in  2. 4.7  below.  The  DTE  may  also 
receive  a  SARM  command  according  to  this  resetting  procedure. 

2. 4, 4. 3  Link  Disconnection 

During  the  information  transfer  phase  the  DTE  shall  indicate  a 
request  for  d  isconnecting  the  link  by  transmitting  a  DISC  command 
to  the  DCE. 

Whenever  receiving  a  DISC  command,  the  DCE  will  return  a  UA 
response  to  the  DTE. 

During  an  information  transfer  phase,  should  the  DCE  wish  to 
indicate  a  request  for  disconnecting  the  link,  or  when  receiving 
from  the  DTE  a  first  DISC  command  as  a  request  for  disconnecting 
the  link,  the  DCE  will  transmit  a  DISC  command  to  the  DTE  and 
start  Timer  T1  (2.4.11.1  below).  The  DTE  will  confirm  reception 
of  the  DISC  command  by  returning  a  UA  response.  After  transmit¬ 
ting  a  SARM  command,  the  DCE  will  not  transmit  a  DISC  command 
until  a  UA  response  is  received  for  this  SARM  command  or  until 
Timer  T1  runs  out. 

When  receiving  a  UA  response  to  the  DISC  command,  the  DCE  will 
stop  its  Timer  Tl.  If;  Timer  T1  runs  out  before  a  UA  response  is 
received  by  the  DCE,  the  DCE  will  transmit  a  DISC  command  and 
restart  Timer  Tl.  After  transmission  of  DISC  N2  times  by  the 
DCE,  appropriate  recovery  action  will  be  initiated.  The  value  of 
N 2  is  defined  in  2.4.11.2  below. 

2,4.5  Procedures  for  Link  Set-up  and  Disconnection  (Applicable 
to  tAPB) 

2 . 4 . 5 . 1  Link  Set-up 

The  DCE  will  indicate  that  it  is  able  to  set  up  the  link  by 
transmitting  contiguous  flags  (active  channel  state). 

Whenever  receiving  an  SABM  command,  the  DCE  will  return  a  UA 
response  to  the  DTE  and  set  both  its  send  and  receive  state  vari¬ 
ables  V(S)  and  V  (R)  to  0. 

Should  the  DCE  wish  to  set-up  the  link,  it  will  send  the  SABM 
cornu  and  and  start  Timer  Tl  (see  2,4.11.1  below).  Upon  reception 
of  the  UA  response  from  the  DTE  the  DCE  resets  both  its  send  and 
receive  state  variables  V (S )  and  V(R)  to  0  and  stops  its  Timer 
Tl. 

Should  Tl  expire  before  reception  of  the  UA  response  from  the 
DTE,  the  DCE  will  retransmit  the  SABM  command  and  rescart  Timer 
Tl.  After  transmission  of  the  SABM  command  N2  times  by  the  DCE, 
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appropriate  recovery  action  will  he  initiated.  The  value  of  N? 
is  defined  in  2.4.11.2  below. 

2. 4.5.2  Information  Transfer  Phase 

After  havinq  transmitted  the  UA  response  to  an  SABM  command  or 
havino  received  the  UA  response  to  a  transmitted  SABM  command, 
the  D'T  will  accept  and  transmit  I  and  S  frames  according  to  the 
procedures  described  in  2.4.f  below. 

When  receiving  an  BARM  command  while  in  the  information  transfer 
phase,  the  DCE  will  conform  to  the  resetting  procedure  described 
in  2 . 4 . 9  below. 

2. 4. 5. 3  Link  Disconnection 

During  the  information  transfer  phase,  the  DTE  shall  indicate 
disconnecting  of  the  link  by  transmitting  a  DISC  command  to  the 
DCE . 

When  receiving  a  DISC  command,  the  DCE  will  return  a  UA  response 
to  the  DTE  and  enter  the  disconnected  phase. 

Should  the  DCE  wish  to  disconnect  the  link,  it  will  send  the  DISC 
command  and  start  Timer  T1  (see  2.4.11.1  below).  Upon  reception 
of  the  UA  response  from  the  DTP,  the  DCE  will  stop  its  Timer  Tl. 

Should  Timer  Tl  expire  before  reception  of  the  UA  response  from 
the  DTE,  the  DCE  will  retransmit  the  DISC  command  and  restart 
Timer  Tl.  After  transmission  of  the  DISC  command  N2  times  by  the 
DCE,  appropriate  recovery  action  will  be  initiated.  The  value  of 
N 2  is  defined  in  2.4.11.2  below. 

2. 4. 5. 4  Disconnected  Phase 


2. 4. 5. 4.1  After  having  received  a  DISC  command  from  the  DTE  and 
returned  a  UA  response  to  the  DTE,  or  having  received  the  UA 
response  to  a  transmitted  DISC  command,  the  DCE  will  enter  the 
disconnected  phase. 

In  the  disconnected  phase,  the  DCE  may  initiate  link  set-up.  In 
the  disconnected  phase,  the  DCE  will  react  to  the  receipt  of  an 
SABM  command  as  described  in  2. 4. 5.1  above  and  will  transmit  a  DM 
response  in  answer  to  a  received  DISC  command. 

When  receiving  any  other  command  frame  with  the  P  bit  set  to  1, 
the  DCE  will  transmit  a  DM  response  with  the  F  bit  set  to  1. 


Other  frames  received  in  the  disconnected  phase  will  be  ignored 
by  the  DCE. 
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2. 4. 5. 4. 2  When  the  DCE  enters  the  disconnected  phase  after 
detecting  error  conditions  as  listed  in  2.4.10  below,  or  excep¬ 
tionally  after  recovery  from  an  internal  temporary  malfunction  it 
may  also  indicate  this  by  sending  a  DM  response  rather  than  a 
DISC  command.  In  these  cases,  the  DCE  will  transmit  DM  and  Btart 
its  Timer  T1  (see  2.4.11.1  below).  If  Timer  T1  runs  out  before 
the  reception  of  an  SABM  or  DISC  command  from  the  DTE,  the  DCE 
will  retransmit  the  DM  response  and  restart  Timer  Tl. 

After  transmission  of  the  DM  response  N2  times,  the  DCE  will 
remain  in  the  disconnected  phase  and  appropriate  recovery  actions 
will  be  initiated.  The  value  of  N2  Is  defined  in  2.4.11.2  below. 

2. 4. 5. 5  Collision  of  Unnumbered  Commands 

Collision  situations  shall  be  resolved  in  the  following  way. 

2. 4. 5. 5.1  If  the  sent  and  received  U  commands  are  the  same,  the 
DTE  and  DCE  shall  send  the  UA  response  at  the  earliest  possible 
opportunity.  The  DCE  shall  enter  the  indicated  phase  after 
receiving  the  UA  response, 

2. 4. 5. 5. 2  If  the  sent  and  received  U  commands  are  different,  the 
DTE  and  DCE  shall  enter  the  disconnected  phase  and  issue  a  DM 
response  at  the  earliest  possible  opportunity. 

2. 4. 5. 6  Collision  of  DM  Response  with  SABM  or  DISC  Command 

When  a  DM  response  is  issued  by  the  DCE  as  an  unsolicited 
response  to  request  the  DTE  to  issue  a  mode-setting  command  as 
described  in  2. 4. 5. 4. 2,  a  collision  between  a  SABM  or  DISC  com¬ 
mand  issued  by  the  DTE  and  the  unsolicited  DM  response  issued  by 
the  DCE  may  occur.  In  order  to  avoid  misinterpretation  of  the  DM 
received,  it  is  suggested  that  the  DTE  always  will  send  its  SABM 
or  DISC  command  with  the  P  bit  set  to  1. 

2.4.5  Procedures  for  Information  Transfer  (Applicable  to  Both 
LAP  and  LAPB ) 

The  procedures  which  apply  to  the  transmission  of  I  frames  in 
each  direction  during  the  information  transfer  phase  are 
described  below. 

In  the  following,  "number  one  higher"  is  in  reference  to  a  con¬ 
tinuously  repeated  sequence  series,  l.e.,  7  is  one  higher  than  fi 
and  0  is  one  higher  than  7  for  modulo  eight  series. 

2,4.6. 1  Sending  I  Frames 

Wh«n  the  DCE  has  an  I  frame  to  transmit  (i.e.,  an  I  frame  not 
already  transmitted,  or  having  to  be  retransmitted  as  described 
in  2. 4. 6, 5  below),  it  will  transmit  it  with  an  N(S)  equal  to  its 
current  send  state  variable  V(S),  and  an  N(R)  equal  to  its 
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current  receive  state  variable  V(R).  At  the  end  of  the  transmis¬ 
sion  of  the  T  frame.  It  will  increment  its  send  state  variable 
V  (S )  by  one . 

If  the  Timer  T1  is  not  running  at  the  instant  of  transmission  of 
an  T  frame,  it  will  be  started. 

If  the  send  state  variable  V  ( S )  is  equal  to  the  last  value  of 
N  (R  1  received  plus  k  (where  k  is  the  maximum  number  of  outstand¬ 
ing  T  frames  -  see  P.4.11.4  below)  the  DCE  will  not  transmit  any 
new  I  frames,  but  may  retransmit  an  I  frame  as  described  in 
2. 4. 6. 5  or  7.4.6.P  below. 

Note :  In  order  to  ensure  security  of  information  transfer,  the 

DTE  should  not  transmit  any  I  frame  if  its  send  state 
variable  V(S)  is  equal  to  the  last  value  of  N (R )  it  has 
received  from  the  DCE  plus  7. 

When  the  DCE  is  in  the  busy  condition  it  may  still  transmit  I 
frames,  provided  that  the  DTE  is  not  busy  itself.  When  the  DCE 
is  in  the  command  rejection  condition  (LAP),  it  may  still 
transmit  I  frames.  When  the  DCE  is  in  the  frame  rejection  condi¬ 
tion  (LAPB) ,  it  will  stop  transmitting  I  frames. 

2. 4.6.2  Receiving  an  I  Frame 

2. 4 . fi. 2. 1  When  the  DCE  is  not  in  a  busy  condition  and  receives 
with  the  correct  FCS  an  I  frame  whose  send  sequence  number  is 
equal  to  the  DCE  receive  state  variable  V(R),  the  DCE  will  accept 
the  information  field  of  this  frame,  increment  by  one  its  receive 
state  variable  V(R),  and  act  as  follows: 

i)  If  an  I  frame  is  available  for  transmission  by  the  DCE, 
it  may  act  as  in  2.4.6.  1  above  and  acknowledge  the 
received  I  frame  by  setting  N(R)  in  the  control  field 
of  the  next  transmitted  I  frame  to  the  value  of  the  DCE 
receive  state  variable  V(R).  The  DCE  may  also  ack¬ 
nowledge  the  received  I  frame  by  transmitting  an  RR 
with  the  N (R )  equal  to  the  value  of  the  DCE  receive 
state  variable  V(R). 

ii)  If  no  I  frame  is  available  for  transmission  by  the  DCE, 
it  will  transmit  an  RR  with  the  N(R)  equal  to  the  value 
of  the  DCE  receive  state  variable  V(R). 

2. 4. 6. 2. 2  When  the  DCE  is  in  a  busy  condition,  it  may  ignore  the 
information  field  contained  in  any  received  I  frame. 

Note:  Zero  length  information  fields  shall  not  be  passed  to  the 
Packet  Level  and  this  situation  should  be  indicated  to  the 
Packet  Level . 


2. 4.  ft. 3  Reception  of  Incorrect  Frames 

When  the  DCF  receives  a  frame  with  an  incorrect  FCR  or  receives 
an  invalid  frame  (see  2.2.9),  this  frame  will  be  discarded. 

When  the  DCE  receives  an  I  frame  whose  FCS  is  correct,  but  whose 
send  sequence  number  is  incorrect,  i.e.,  not  equal  to  the  current 
DCE  receive  state  variable  V(R),  it  will  discard  the  information 
field  of  the  frame  and  transmit  an  REJ  response  with  the  N(R)  set 
to  one  higher  than  the  N(S)  of  the  last  correctly  received  1 
frame.  The  DCE  will  then  discard  the  information  field  of  all  I 
frames  until  the  expected  I  frame  is  correctly  received.  When 
receiving  the  expected  I  frame,  the  DCE  will  then  acknowledge  the 
frame  as  described  in  7.4. ft. 2  above.  The  DCE  will  use  the  N(R) 
and  P  bit  indications  in  the  discarded  I  frames. 

2. 4.  ft. 4  Receiving  Acknowledgement 

When  correctly  receiving  an  I  or  S  frame  (RR,  RNR  or  REJ),  even 
in  the  busy  or  command  rejection  condition,  the  DCE  will  consider 
the  N  (R )  contained  in  this  frame  as  an  acknowledgement  for  all 
the  I  frames  it  has  transmitted  with  an  N(S)  up  to  and  including 
the  received  N (R )  minus  one.  The  DCE  will  reset  the  Timer  T1 
when  it  correctly  receives  an  I  or  S  frame  with  the  N (R )  higher 
than  the  last  received  N(R)  (actually  acknowledging  some  I 
frames) . 

If  the  timer  has  been  reset,  and  if  there  are  outstanding  I 
frames  still  unacknowledged,  it  will  restart  the  Timer  Tl.  If 
the  timer  then  runs  out,  the  DCE  will  follow  the  retransmission 
procedure  (in  2. 4. 6. 5  and  2. 4. ft. 8  below)  with  respect  to  the 
unacknowledged  I  frames. 

2. 4.  ft. 5  Receiving  Reject 

When  receiving  an  REJ,  and  DCE  will  set  its  send  state  variable 
V (S )  to  the  N (R )  received  in  the  REJ  control  field.  It  will 
transmit  the  corresponding  I  frame  as  soon  as  it  is  available  or 
retransmit  it.  (Re)  transmission  will  conform  to  the  £- :  .  -  vi  -'g  : 

i)  If  the  DCE  is  transmitting  a  supervisory  or  unnumbered 
command  or  response  when  it  receives  the  REJ,  it  will 
complete  that  transmission  before  commencing  transmis¬ 
sion  of  the  requested  I  frame. 

ii)  If  the  DCE  is  transmitting  an  I  frame  when  the  REJ  is 
received,  it  may  abort  the  I  frame  and  commence 
transmission  of  the  reauested  I  frame  immediately  after 
abortion. 

iii)  If  the  DCE  is  not  transmitting  any  frame  when  the  REJ 
is  received,  it  will  commence  transmission  of  the 
requested  I  frame  immediately. 
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In  all  rape?,  if  other  unacknowl edqed  I  frames  had  already  been 
transmitted  following  the  one  indicated  in  the  REJ,  then  those  T 
frames  will  be  retransmitted  hy  the  DCE  following  the  retransmis¬ 
sion  of  the  requ^stP'5  I  frame. 

If  the  REJ  frame  was  received  from  the  PTE  as  a  command  with  the 
P  bit  set  to  1,  the  Drp  will  transmit  an  RR  or  RNR  response  with 
the  F  bit  set  to  1  before  transmitting  or  retransmitting  the 
corresponding  1  frame. 

7.4. P.P  Receiving  RNR 

After  receiving  an  RNR,  the  DCE  may  transmit  or  retransmit  the  I 
fraii  e  with  the  send  sequence  number  equal  to  the  N(R)  indicated 
in  the  RNR.  If  the  Timer  T1  runs  out  after  the  reception  of  RNR, 
the  DCE  will  follow  the  procedure  described  in  2.4.P.P  below.  In 
any  case  the  DCE  will  not  transmit  any  other  I  frames  before 
receiving  an  RR  or  REJ. 

2. 4.  P.7  DCE  Busy  Condition 

When  the  DCE  enters  a  busy  condition,  it  will  transmit  an  RNR 
response  at  the  earliest  opportunity.  While  ii  the  busy  condi¬ 
tion,  the  DCE  will  accept  and  process  S  frames  and  return  an  RNR 
response  with  the  F  bit  set  to  1  if  it  receives  an  S  or  I  command 
frame  with  the  P  bit  set  to  1.  To  clear  the  busy  condition,  the 
DCE  will  transmit  either  an  RE.I  response  or  an  RR  response  with 
N (R 1  set  to  the  current  receive  state  variable  V(R)  depending  on 
whether  or  not  it  discarded  information  fields  of  correctly 
received  T  frames. 

Note :  The  DTE  when  encountering  a  DCE  busy  condition,  may  send 

supervisory  command  frames  with  the  P  bit  set  to  1.  In 
the  event  that  the  DTE  has  not  implemented  supervisory 
commands,  it  may  follow  the  procedures  of  the  DCE  (see 

2.4.P.P)  (applicable  to  LAPR) . 

7 . 4 .  fi . P  Waiting  Acknowledgement 

The  DCE  maintains  an  internal  retransmission  count  variable  which 
is  set  to  P  when  the  DCE  receives  a  UA  or  RNR,  or  when  the  DCE 
correctly  receives  an  I  or  S  frame  with  the  N(R)  higher  than  the 
last  received  N  (R )  (actually  acknowl edg i ng  some  outstanding  I 
frames) . 

If  the  Timer  T1  runs  out,  the  DCE  will  (re-)enter  the  timer 
recovery  condition,  add  one  to  its  retransmission  count  variable 
and  set  an  interna]  variable  X  to  the  current  value  of  its  send 
state  variable. 

The  DCE  will  restart  Timer  Tl,  set  its  send  state  variable  to  the 
last  N(R)  received  from  the  DTE  and  retransmit  the  corresponding 
1  frame  with  the  P  bit  set  to  1  (LAP  or  LAPB)  or  transmit  an 
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appropriate  supervisory  command  with  the  P  bit  set  to  ]  (LAPB 
only)  . 

The  timer  recovery  condition  is  cleared  when  the  DCE  receives  a 
valid  S  frame  from  the  DTE,  with  the  F  bit  set  to  1. 

If,  while  in  the  timer  recovery  condition,  the  DCE  correctly 
receives  a  supervisory  frame  with  the  F  bit  set  to  1  and  with  the 
N (R )  within  the  ranqe  from  its  current  send  state  variable  to  X 
included,  it  will  clear  the  timer  recovery  condition  and  set  its 
send  state  variable  to  the  received  N(R). 

If,  while  in  the  timer  recovery  condition,  the  DCE  correctly 
receives  a  supervisory  frame  with  the  F  bit  set  to  0  and  with  an 
N(R)  within  the  range  from  its  current  send  state  variable  to  X 
included,  it  will  not  clear  the  timer  recovery  condition.  The 
received  N(R)  may  be  used  to  update  the  send  state  variable. 
However,  the  DCE  may  decide  to  keep  the  last  transmitted  I  frame 
in  store  (even  if  it  is  acknowledged)  in  order  to  be  able  to 
retransmit  it  with  the  P  bit  set  to  1  when  Timer  T1  expires  at  a 
later  time. 

If  the  retransmission  count  variable  is  equal  to  N2,  the  DCE  ini¬ 
tiates  a  resetting  procedure  for  the  direction  of  transmission 
from  the  DCE  as  described  in  2. 4. 7. 3,  2. 4. 9. 2  or  2. 4.9. 3  below. 

N 2  is  a  system  parameter  (see  2.4.11.2  below). 

Note :  Although  the  DCE  will  implement  the  internal  variable  X, 

other  mechanisms  do  exist  that  achieve  the  identical  func¬ 
tions.  Therefore,  the  internal  variable  X  is  not  neces¬ 
sarily  implemented  in  the  DTE, 

2.4.7  Procedures  for  Resetting  (Applicable  to  LAP) 

2.4.7. 1  The  resetting  procedure  is  used  to  reinitialize  one 
direction  of  information  transmission,  according  to  the  procedure 
described  below.  The  resetting  procedure  only  applies  during  the 
information  transfer  phase. 

2. 4. 7. 2  The  DTE  will  indicate  a  resetting  of  the  information 
transmission  from  the  DTE  by  transmitting  an  SARM  command  to  the 
DCE.  When  receiving  an  SARM  command,  the  DCE  will  return,  at  the 
earliest  opportunity,  a  UA  response  to  the  DTE  and  set  its 
receive  state  variable  V(R)  to  n.  This  also  indicates  a  clear¬ 
ance  of  the  DCE  busy  condition,  if  present. 

2. 4. 7. 3  The  DCE  will  indicate  a  resetting  of  the  information 
transmission  from  the  DCE  by  transmitting  an  SARM  command  to  the 
DTE  and  will  start  Timer  T1  (see  2.4.11.1  below).  The  DTE  will 
confirm  reception  of  the  SARM  command  by  returning  a  UA  response 
to  the  DCE.  When  receiving  this  UA  response  to  the  SARM  command, 
the  DCE  will  set  its  send  state  variable  to  0  and  stop  its  Timer 
Tl.  If  Timer  T1  runs  out  before  the  UA  response  is  received  by 


3D 


the  DCE,  the  DCF  will  retransnit  an  EAR*!  command  and  restart 
Timer  Tl.  After  transmission  of  SAR^  N?  times,  appropriate 
recovery  action  will  hr  initiated.  The  value  of  N7  is  defined  in 
? .  4 .  1  1 .  7  below. 

The  DCF  will  not  act  on  any  received  response  frame  which  arrives 
before  the  UA  response  to  the  SAR*  command.  The  value  of  N  (R  ) 
contained  in  any  correctly  received  T  commend  frames  arrivin'] 
before  the  UA  response  will  also  be  ignored. 

?. 4.7.4  When  receivinq  a  CMDR  response  from  the  DTE,  the  DCE 
will  initiate  a  resettinq  of  the  information  transmission  from 
the  DCE  as  described  in  3.4. 7. 3  above. 

2.4.7.E  if  the  DCE  transmits  a  CMDR  response,  it  enters  the  com¬ 
mand  rejection  condition.  This  command  rejection  condition  is 
cleared  when  the  DCE  receives  an  5ARM  or  DISC  command.  Any  other 
cour and  received  while  in  the  command  rejection  condition  will 
cause  the  DCE  to  retransmit  this  CMDR  response.  The  coding  of 
the  C*IPR  response  will  be  as  described  in  2.3.4.10  above. 

2 . 4 . 8  Rejection  Conditions  (Applicable  to  LAP) 

2.4.P.]  Rejection  Conditions  Causing  a  Resetting  of  the 
Transmission  o f  Information  from  the  DCE 

The  DCE  will  initiate  a  resetting  procedure  as  described  in 

2. 4. 7. 3  above  when  receiving  a  frame  with  the  correct  FCS,  with 
the  address  A  (coded  11000000)  and  with  one  of  the  follow¬ 
ing  conditions: 

-  the  frame  type  is  unknown  as  one  of  the  responses  used; 

-  the  information  field  is  invalid; 

-  the  N  (R )  contained  in  the  control  field  is  invalid; 

-  the  response  contains  an  F  bit  set  to  1  except  during  a 
timer  recovery  condition  as  described  in  2. 4. 6. 8  above. 

The  DCE  will  also  initiate  a  resetting  procedure  as  described  in 

2.4.7. 3  above  when  receiving  an  I  frame  with  correct  FCS,  with 
the  address  B  (coded  1DD0D00D)  and  with  an  invalid  N(R) 
contained  in  the  control  field. 

A  valid  N (R )  must  be  within  the  range  from  the  lowest  send 
sequence  number  N  (E  )  of  the  still  unacknowledged  frame(s)  to  the 
current  DCE  send  state  variable  included,  even  If  the  DCE  is  in  a 
rejection  condition,  but  not  if  the  DCE  is  in  the  timer  recovery 
condition  (see  2. 4.6. 8  above). 
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2.4. P . 2  Rejection  Condition?  Censing  the  DCE  to  Request  ^  Reset¬ 
ting  o f  the  Transmission  of  Information  from  the  DTK 

The  DCE  will  enter  th«'  command  rejection  condition  as  described 
in  2. A.  7. 5  above  when  receiving  a  frame  with  the  correct  FCS, 
witi  the  address  B  (coded  10000000)  and  with  one  of  the 
following  conditions: 

-  the  frame  type  is  unknown  as  one  of  the  commands  used; 

-  the  information  field  is  invalid. 

2.4.9  Procedures  for  Resetting  (Applicable  to  LAPB) 

2. 4. 9.1  The  resetting  procedures  are  used  to  initialize  both 
directions  of  information  transmission  according  to  the  procedure 
described  below.  The  resetting  procedures  only  apply  during  the 
information  transfer  phase. 

2. A. 9. 2  The  DTE  or  DCE  shall  indicate  a  resetting  by  transmit¬ 
ting  an  SABM  command.  After  receiving  an  Sabm  command,  the  DCE 
or  DTE,  respectively,  will  return,  at  the  earliest  opportunity,  a 
UA  response  to  the  DTE  or  DCE,  respectively,  and  reset  its  send 
and  receive  state  variables  V(S)  and  V (R )  to  0.  This  also  clears 
a  DCE  and/or  DTE  busy  condition,  if  present.  Prior  to  initiating 
this  link  resetting  procedure,  the  DTE  or  DCE  may  initiate  a 
disconnect  procedure  as  described  in  2. 4. 5. 3  above. 

2. 4. 9. 3  Under  certain  rejection  conditions  listed  in  2.4.6.R 
above  and  2.4.10.2  below,  the  DCE  may  ask  the  DTE  to  reset  the 
link  by  transmitting  a  DM  response. 

After  transmitting  a  DM  response,  the  DCE  will  enter  the  discon¬ 
nected  phase  as  described  in  2. 4. 5. 4. 2  above. 

2. 4. 9. 4  Under  certain  rejection  conditions  listed  in  2.4.10.1 
below,  the  DCE  may  ask  the  DTE  to  reset  the  link  by  transmitting 
a  FRMR  response. 

After  transmitting  a  FRMR  response,  the  DCE  will  ente.  the  frame 
rejection  condition.  The  frame  rejection  condition  is  cleared 
when  the  DCE  receives  an  SABM  or  DISC  command  or  DM  response. 

Any  other  command  received  while  in  the  frame  rejection  condition 
will  cause  the  DCE  to  retransmit  the  FRMR  response  with  the  same 
information  field  as  originally  transmitted. 

The  DCE  may  start  a  Timer  T1  on  transmission  of  the  FRMR 
response.  If  Timer  T1  runs  out  before  the  reception  of  an  SABM 
or  DISC  command  from  the  DTE,  the  DCE  may  retransmit  the  FRMR 
response  and  restart  Timer  Tl.  After  transmission  of  the  FRMR 
response  N2  times  the  DCE  may  reset  the  link  as  described  in 

2. 4. 9. 2  above.  The  value  of  N2  is  defined  in  2.4.11.2  below. 
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7.4.  10  Rejection  ['ouMtionf  (Applicable*  to  LAPP) 

7.4.10,]  The  DCF  wi 1 ]  initiate  a  resetting  procedure  as 
described  in  ?.4.n,4  above,  when  receiving,  during  the  informa¬ 
tion  transfer  phase,  a  frame  with  the  correct  FCS,  with  the 
address  A  or  A,  an.’  with  one  of  the  following  conditions: 

-  the  f  [  t'np  is  unknown  as  a  command  or  as  a  response; 

-  the  information  field  is  invalid; 

-  the  N  (R )  contained  in  the  control  field  is  invalid  as 
describe!  in  7.4.P.1  above. 

The  coding  of  the  information  field  of  the  FRMR  response  which  is 
transmitted  is  aiven  in  2.3.4.10  above.  Bit  13  of  this  informa¬ 
tion  field  is  set  to  0  if  the  address  of  the  rejected  frame  is  B. 
It  is  set  to  1  i f  the  address  is  A. 

2.4.10.2  The  DCE  will  initiate  a  resetting  procedure  as 
described  in  2.4.9.?  or  ?.4.Q.3  above  when  receiving  during  the 
information  transfer  phase  a  DM  response  or  a  FRMR  response. 

The  DTE  may  initiate  a  resetting  procedure  as  described  in 

2. 4.  R.2  or  2.4,n.i  above  when  receiving  during  the  information 
transfer  phase  a  UA  response  or  an  unsolicited  response  with  the 
F  bit  set  to  1 . 

2.4,11  List  o f  System  P  a  r  ameters  (Applicable  to  Both  LAP  and 
LAPP' 

The  system  parameters  are  as  follows: 

2.4,11.1  Timer  Tl 

The  period  o r  the  Timer  T1  will  take  into  account  whether  the 
timer  is  started  at  the  beginning  or  the  end  of  the  frame  in  the 
DCE. 

The  period  of  the  Timer  Tl,  at  the  end  of  which  retransmission  of 
a  frame  may  be  initiated  according  to  the  procedures  described  in 
2.4.4  to  2.4.P  above,  is  a  system  parameter  agreed  for  a  period 
of  time  with  the  Administration. 

The  proper  operation  of  the  procedure  requires  that  Timer  Tl  be 
greater  than  uhe  maximum  time  between  transmission  of  frames 
(SARM,  SABM,  DM,  DT^C,  FRMR,  T  or  supervisory  commands)  and  the 
reception  of  the  corresponding  frame  returned  as  an  answer  to 
this  frame  (UA,  DM  or  acknowledging  frame).  Therefore,  the  DTE 
should  not  delay  the  response  or  acknowledging  frame  returned  to 
the  above  frames  by  more  than  a  value  T?  less  than  Tl,  where  T2 
is  a  system  parameter. 
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The  P<"K  will  not  delay  the  response  or  acknow)  edg  i  ng  frame 
returned  to  a  command  by  more  than  T?. 

2.4.11.?  Maximum  Number  of  Transmissions  N? 

The  value  of  the  maximum  number  N2  of  transmission  and 
retransmissions  of  a  frame  following  the  running  out  of  Timer  T1 
is  a  system  parameter  agreed  for  a  period  of  time  with  the 
Administration . 

2.4.11.3  Maximum  Number  of  Bits  in  an  I  Frame  N1 

The  maximum  number  of  bits  in  an  I  frame  is  a  system  parameter 
which  depends  upon  the  maximum  length  of  the  information  fields 
transferred  across  the  DTE/DCE  interface. 

2.4.11.4  Maximum  Number  of  Outstanding  I  Frames  k 

The  maximum  number  (k)  of  sequentially  numbered  I  frames  that  the 
DTE  or  DCE  may  have  outstanding  (i.e.,  unacknowledged)  at  any 
given  time  is  a  system  parameter  which  can  never  exceed  seven. 

It  shall  be  agreed  for  a  period  of  time  with  the  Administration. 

Note :  As  a  result  of  the  further  study  proposed  in  2.2.4  above, 
the  permissible  maximum  number  of  outstanding  I  frames  may 
be  increased. 

3.  DESCRIPTION  OF  THE  PACKET  LEVEL  DTE/DCE  INTERFACE 

This  and  subsequent  sections  of  the  recommendation  relate  to  the 
transfer  of  packets  at  the  DTE/DCE  interface.  The  procedures 
apply  to  packets  which  are  successfully  transferred  across  the 
DTE/DCE  interface. 

Each  packet  to  be  transferred  across  the  DTE/DCE  interface  shall 
be  contained  within  the  link  level  information  field  which  will 
delimit  its  length,  and  only  one  packet  shall  be  contained  in  the 
information  field. 


Note  1:  Possible  insertion  of  more  than  one  packet  in  the  link 
level  information  field  is  tor  further  study. 

Note  2;  At  present,  some  networks  require  the  data  fields  of 
packets  to  contain  an  integral  number  of  octets.  The 
transmission  by  the  DTE  of  data  fields  not  containing  an 
integral  number  of  octets  to  the  network  may  cause  a 
loss  of  data  integrity. 


Under  urgent  study  are  further  considerations  regarding 
the  trends  of  future  requirements  and  implementations 
toward  either  bit-orientation  (any  number  of  bits!  or 
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or  t  e  t --o  r  i  on  t  a  t  i  on  (  an  integral  number  of  octets)  for 
r?  <*>  t  .  i  fi  elf's  in  X .  packets. 

T'TF.s  wishino  universal  operation  on  a]]  networks  shou) 
transmit  >  1  1  packets  witti  data  fields  containing  only  an 
integral  number  of  octets.  Full  data  integrity  ran  only 
be  assure'  by  exchanop  of  ortet-oriented  data  fields  in 
both  directions  of  transmission. 

This  section  covers  a  description  of  the  packet  level  interface 
for  virtual  call,  permanent  virtual  circuit  and  datagram  ser¬ 
vices.  As  designated  in  Re  commend  a t i o n  X.?,  virtual  call  and 
permanent  virtual  circuit  services  are  essentia]  (E)  services  to 
be  provided  by  all  networks.  Datagram  service  is  designated  as 
an  additional  (A1  service  which  may  be  provided  by  some  networks. 

Note:  Under  study  are  cons i d er a t i ons  reqarding  the  amount  of 

possible  duplication  between  datagram,  fast  select  and 
possible  additional  virtual  cal)  enhancements  with  the 
objective  to  minimize  the  variety  of  interfaces. 

Procedures  for  virtual  circuit  service  (i.e.,  virtual  call  and 
permanent  virtual  circuit  services)  are  specified  in  section  4. 
Procedures  for  the  datagram  service  are  specified  in  section  5. 
Paciet  formats  tor  all  services  are  specified  in  section  R.  Pro¬ 
cedures  and  formats  for  optional  user  facilities  are  specified  in 
sec t i on  7  . 

7.  1  L  o  a  1 c  a  1  Channels 

To  enable  simultaneous  virtual  calls  and/or  permanent  virtual 
circuits  and/or  datagrams,  logical  channels  are  used.  Each  vir¬ 
tual  call,  permanent  virtual  circuit,  and  datagram  channel  is 
assigned  a  Logical  Channel  Group  Number  (less  than  or  equal  to 
15)  and  a  Logical  Channel  Number  (less  than  or  equal  to  255). 

For  virtual  calls,  a  Logical  Channel  Group  Number  and  a  Logical 
Channel  Number  are  assigned  during  the  call  set-up  phase.  The 
range  of  logical  channels  used  for  virtual  calls  is  agreed  with 
the  Administration  at  the  time  of  subscription  to  the  service 
(see  Annex  1).  For  permanent  virtual  circuits  and  datagram  chan¬ 
nels,  Logical  Channel  Group  Numbers  and  Logical  Channel  Numbers 
are  ass  gned  in  agreement  with  the  Administration  at  the  time  of 
subscription  to  the  service  (see  Annex  1). 

3 .  2  B a sj_ c  Structure  of  P a ckets 

Every  packet  transferred  across  the  DTE/DCE  interface  consists  of 
at  least  3  octets.  These  three  octets  contain  a  general  format 
identifier,  a  logical  channel  identifier  and  a  packet  type  iden¬ 
tifier.  Other  packet  fields  are  appended  as  required  (see  sec¬ 
tion  5  )  . 


Packet  types  and  their  use  in  association  with  various  services 
are  given  in  Table  3.1/X.?C. 
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TABLE  3.1/X.25 

PACKET  TYPES  AND  THEIR  USE  IN 
VARIOUS  SERVICES 


PACKET 

TYPE 

SERVICE 

FROM  DCE  TO  DTE 

FROM  DTE  TO  DCE 

VC 

PVC  DG  * 

CALL  SET-UP  AND  CLEARING  (Note  1) 

INCOMING  CALL 

CALL  REQUEST 

X 

CALL  CONNECTED 

CALL  ACCEPTED 

X 

CLEAR  INDICATION 

CLEAR  REQUEST 

X 

DCE  CLEAR  CONFIRMATION 

DTE  CLEAR  CONFIRMATION 

X 

DATA  AND  INTERRUPT  (Note  2) 

DCE  DATA 

DTE  DATA 

X 

X 

DCE  INTERRUPT 

DTE  INTERRUPT 

X 

X 

DCE  INTERRUPT 

DTE  INTERRUPT 

CONFIRMATION 

CONFIRMATION 

X 

X 

DATAGRAM 

(Note  3) 

DCE  DATAGRAM 

DTE  DATAGRAM 

X 

DATAGRAM  SERVICE  SIGNAL 

X 

FLOW  CONTROL  AND 

RESET  (Note  4) 

DCE  RR 

DTE  RR 

X 

X  X 

DCE  RNR 

DTE  RNR 

X 

X  X 

DTE  REJ* 

X 

X  X 

RESET  INDICATION 

RESET  REQUEST 

X 

X  X 

DCE  RESET  CONFIRMATION 

DTE  RESET  CONFIRMATION 

X 

X  X 

RESTART  (Note  5) 

RESTART  INDICATION 

RESTART  REQUEST 

X 

X  X 

DCE  RESTART  CONFIRMATION 

DTE  RESTART  CONFIRMATION 

X 

X  X 

DIAGNOSTIC 

(Note  6) 

DIAGNOSTIC* 

X 

X  X 

*  Not  necessarily  available  on  all  networks. 

VC  ■  Virtual  call 
PVC  »  Permanent  virtual  circuit 
DC  ■  Datagram 


XX  X  X  X  X  X 
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Not  r  1:  Pee  sections  ''.l  and  7.  2. 'I  for  procedures  and  sectionr. 


f..  2  and  A.  P. 

?  for  formats. 

Note 

2: 

Sep  sprtinn 
mats. 

4.3  for  procedures 

and 

sec  t i on 

A.  3 

for 

fo  r- 

Note 

1 : 

Fee  section 
rets. 

5.  1  for  procedures 

and 

section 

A.  4 

for 

for- 

Note 

1- 

P<>e  sections 
t i o  n  A  .  A  and 

4.4,  5.2  and  -7.1.4 
A . p . ]  for  formats. 

for 

procedures 

and 

sec- 

Note 

A  ; 

Fee  section 
mats. 

7.7  for  procedures 

and 

sec  t i on 

A.  A 

for 

fo  r- 

Note 

See  section 

3.4  for  procedures 

and 

section 

A. 7 

for 

for- 

mat  s  . 

3 . 3  Procedure  for  Restart 

The  restart  procedure  is  used  to  initialize  or  r e- i n i t i al i ze  the 
packet  level  DTE/DCE  interface.  The  restart  procedure  simultane¬ 
ously  clears  all  the  virtual  calls  and  resets  all  the  permanent 
virtual  circuits  and  datagram  channels  at  the  DTE/DCE  interface 
(see  sections  4.5  and  5.3). 

Annex  2,  Figure  A2.1/X.25  gives  the  state  diagram  which  defines 
the  logical  relationships  of  events  related  to  the  restart  pro- 
ced  ure . 

Annex  3,  Table  A3.2/X.25  specifies  actions  taken  by  the  DCE  on 
the  receipt  of  packets  from  the  DTE  for  the  restart  procedure. 
Details  of  the  action  which  should  be  taken  by  the  DTE  are  for 
further  study. 

3.3.1  Restart  by  the  DTE 

The  DTE  may  at  any  time  request  a  restart  by  transferring  across 
the  DTE/DCF  interface  a  RESTART  REQUEST  packet.  The  interface 
for  each  loqical  channel  is  then  in  the  DTE  RESTART  REQUEST  state 
(  r  2 )  . 

The  DCE  will  confirm  the  restart  by  transferring  a  DCE  RESTART 
CONFIRMATION  packet  placing  the  logical  channels  used  for  virtual 
calls  in  the  READY  state  (pi),  and  the  logical  channels  used  for 
permanent  virtual  circuits  and  datagrams  in  the  FLOW  CONTROL 
READY  state  <dl ) . 

Note ;  States  pi  and  dl  are  specified  in  sections  4  and  5. 

The  DCE  RESTART  C ONF IRM ATION  packet  can  only  be  interpreted 
universally  as  having  local  significance.  The  time  spent  in  the 
DTE  RESTART  REQUEST  state  ( r  2 )  will  not  exceed  time-limit  T2(! 


37 


(see  Annex  4  )  . 

3 .  1 .  2  Restart  by  the  DCF. 

The  DCE  may  indicate  a  restart  by  transferring  across  the  DTE/DCE 
interface  a  RESTART  INDICATION  packet.  The  interface  for  each 
logical  channel  is  then  in  the  DCE  RESTART  INDICATION  state  ( r 3 1 . 
In  this  state  of  the  DTE/DCE  interface,  the  DCE  will  ignore  all 
packets  except  for  RESTART  REQUEST  and  DTE  RESTART  CONFIRMATION. 

The  DTE  will  confirm  the  restart  by  transferring  a  DTE  RESTART 
CONFIRMATION  packet  placing  the  logical  channels  used  for  virtual 
calls  in  the  READY  state  (pi),  and  the  logical  channels  used  for 
permanent  virtual  circuits  and  datagrams  in  the  FLOW  CONTROL 
READY  state  (dl ) . 

The  action  taken  by  the  DCE  when  the  DTE  does  not  confirm  the 
restart  within  time-out  Tin  is  given  in  Annex  4. 

3.3.3  Restart  Collision 

Restart  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
transfer  a  RESTART  REQUEST  and  a  RESTART  INDICATION  packet. 

Under  this  circumstance,  the  DCE  will  consider  that  the  restart 
is  completed.  The  DCE  will  not  expect  a  DTE  RESTART  CONFIRMATION 
packet  and  will  not  transfer  a  DCE  RESTART  CONFIRMATION  packet. 
This  places  the  logical  channels  used  for  virtual  calls  in  the 
READY  state  (pi),  and  the  logical  channels  used  for  permanent 
virtual  circuits  and  datagrams  in  the  FLOW  CONTROL  READY  state 
( d1  )  . 

3. 4  Error  Handling 

Table  A3.1/X.25  specifies  the  reaction  of  the  DCE  when  special 
error  conditions  are  encountered.  Other  error  conditions  are 
discussed  in  sections  4  and  5. 

3.4.1  Diagnostic  Packet 

The  DIAGNOSTIC  packet  is  used  by  some  networks  to  indicate  error 
conditions  under  circumstances  when  the  usual  methods  of  indica¬ 
tion  (i.e.,  reset,  clear  and  restart  with  cause  and  diagnostic) 
are  inappropriate  (see  Tables  A3.1/X.25  and  A4.1/X.25).  The 
DIAGNOSTIC  packet  from  the  DCE  supplies  information  on  error 
situations  which  are  considered  unrecoverable  at  the  packet  level 
of  X. 25;  the  information  provided  permits  an  analysis  of  the 
error  and  recovery  by  higher  levels  at  the  DTE  if  desired  or  pos¬ 
sible. 

A  DIAGNOSTIC  packet  is  issued  only  once  per  particular  instance 
of  an  error  condition.  No  confirmation  is  required  to  be  issued 
by  the  DTE  on  rereipt  of  a  DIAGNOSTIC  packet.  After  issuance  of 
a  DIAGNOSTIC  packet,  the  DCE  maintains  the  logical  channel (s)  to 
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which  the  DT  AGNDrT  I packet  is  related  in  the  same  state  as  that 
when  the  riAONO"TTr  packet  was  generated. 

? .  i-  E  f  f  ect  s  of  the  Physical  Level  and  the  Link  Level  on  the 
Packet  Level 

Changes  of  operational  states  of  the  physical  level  and  the  link 
level  of  the  DTE/DPF  interface  do  not  implicitly  change  the  state 
of  each  logical  channel  at  the  packet  level.  Such  changes  when 
they  occur  are  explicitly  indicated  at  the  packet  level  hy  the 
use  of  restart,  clear  or  reset  procedures  as  appropriate. 

A  failure  on  the  physical  and/or  link  level  is  defined  as  a  con¬ 
dition  in  which  the  DCE  cannot  transmit  and  receive  any  frames 
because  of  abnormal  conditions  caused  by,  for  instance,  a  line 
fault  between  DTE  and  DCE. 

Whin  a  failure  on  the  physical  and/or  link  level  is  detected, 
virtual  calls  will  be  cleared,  permanent  virtual  circuits  will  be 
declared  out  of  order  and  queued  datagrams  will  be  discarded. 
Further  actions  are  specified  in  section  4. A  for  virtual  circuit 
services  and  in  section  5.4  for  the  datagram  service. 

When  the  failure  is  recovered  on  physical  and  link  levels,  the 
DCE  will  send  a  RESTART  INDICATION  packet  with  the  cause  "Network 
operational"  to  the  local  DTE.  Further  actions  are  specified  in 
section  4. A  for  virtual  circuit  services  and  in  section  5.4  for 
the  datagram  service. 

In  other  out  of  order  conditions  on  the  physical  and/or  link 
level,  including  transmission  of  a  DISC  command  by  the  DTE,  the 
behavior  of  the  DCE  is  for  further  study. 


4.  PROCEDURES  FOR  VIRTUAL  CIRCUIT  SERVICES 


4 . 1  Procedures  for  Virtual  Call  Service 

Annex  2,  Figures  A2.1/X.25,  A2.2/X.25  and  A7.3/X.25  show  the 
state  diagrams  which  give  a  definition  of  events  at  the  packet 
level  DTE/DCE  interface  for  each  logical  channel  used  for  virtual 
calls. 

Annex  3  gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  2.  Details  of  the 
actions  which  should  be  taken  by  the  DTE  are  for  further  study. 

The  call  set-up  and  clearing  procedures  described  in  the  follow¬ 
ing  sections  apply  independently  to  each  logical  channel  assigned 
to  virtual  call  service  at  the  DTE/DCE  interface. 
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4.1.1  Ready  State 

If  there  is  no  call  in  existence,  a  logical  channel  is  in  the 
READY  state  (pi ) . 

4.1.2  Call  Request  Packet 

The  calling  DTE  shall  indicate  a  call  request  by  transferring  a 
CALL  REQUEST  packet  across  the  DTE/DCE  interface.  The  logical 
channel  selected  by  the  DTE  is  then  in  the  DTE  WAITING  state 
(p2)  .  The  CALL  REQUEST  packet  includes  the  called  DTE  address. 
The  calling  DTE  address  field  may  also  be  used. 

Note  1:  A  DTE  address  may  be  a  DTE  network  address,  an  abbrevi¬ 
ated  address  or  any  other  DTE  identi f ication  agreed  for 
a  period  of  time  between  the  DTE  and  the  DCE. 

Note  2:  The  CALL  REQUEST  packet  should  use  the  logical  channel 
in  the  READY  state  with  the  highest  number  In  the  range 
which  has  been  agreed  with  the  Administration  (see  Annex 
1).  Thus  the  risk  of  call  collision  is  minimized. 

4.1.3  Incoming  Call  Packet 

The  DCE  will  indicate  that  there  is  an  incoming  call  by  transfer¬ 
ring  across  the  DTE/DCE  interface  an  INCOMING  CALL  packet.  This 
places  the  logical  channel  in  the  DCE  WAITING  state  (p3). 

The  INCOMING  CALL  packet  will  use  the  logical  channel  in  the 
READY  state  with  the  lowest  number  (see  Annex  1).  The  INCOMING 
CALL  packet  includes  the  calling  DTE  address.  The  called  DTE 
address  field  may  also  be  used. 

Notes  A  DTE  address  may  be  a  DTE  network  address,  an  abbrevi¬ 
ated  address  or  any  other  DTE  identification  agreed  for 
a  period  of  time  between  the  DTE  and  the  DCE. 

4.1.4  Call  Accepted  Packet 

The  called  DTE  shall  indicate  its  acceptance  of  the  c,?’1  hv 
transferring  across  the  DTE/DCE  interface  a  CALL  ACCEPTED  packet 
specifying  the  same  logical  channel  as  that  of  the  INCOMING  CALL 
packet.  This  places  the  specified  logical  channel  in  the  DATA 
TRANSFER  state  (p4) . 

If  the  called  DTE  does  not  accept  the  call  by  a  CALL  ACCEPTED 
packet  or  does  not  reject  it  by  a  CLEAR  REQUEST  packet  as 
described  in  section  4.1.7  within  time-out  Til  (see  Annex  4),  the 
DCE  will  consider  it  as  a  procedure  error  from  the  called  DTE  and 
will  clear  the  virtual  call  according  to  the  procedure  described 
in  section  4.1.8. 
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4 .  1 . S  Call  Connected  Packet 

The  receipt  of  a  fM.L  CONNECTED  packet  by  the  calling  PTE  speci¬ 
fying  the  samp  logical  channel  as  that  specified  in  the  CALL 
REQUEST  packet  indicates  that  the  call  has  been  accepted  by  the 
caller?  PTE  by  means  of  a  CALL  ACCEPTED  packet.  This  places  tin 
specified  logical  channel  in  the  DATA  TRANSFER  state  (p4). 

The  time  spent  in  the  DTE  WATTING  state  (p2)  will  not  exceed 
time-limit  T21  (see  Annex  4). 

4 . 1 . A  Call  Col  1 ision 

Call  collision  occurs  when  a  DTE  and  DCE  simultaneously  transfer 
a  CALL  REQUEST  packet  and  an  INCOMING  CALL  packet  specifying  the 
same  logical  channel .  The  DCE  will  proceed  with  the  call  request 
and  cancel  the  incoming  call. 

4.1.7  Clearing  by  the  DTE 

At  c.ny  time  the  DTE  may  indicate  clearing  by  transferring  across 
the  DTE/DCE  interface  a  CLEAR  REQUEST  packet  (see  section  4.5). 
The  logical  channel  is  then  in  the  DTE  CLEAR  REQUEST  state  (pR). 
When  the  DCE  is  prepared  to  free  the  logical  channel,  the  DCE 
will  transfer  across  the  DTE/DCE  interface  a  DCE  CLEAR  CONFIRMA¬ 
TION  packet  specifying  the  logical  channel.  The  logical  channel 
is  now  in  the  READY  state  (pi). 

The  DCE  CLEAR  CONFIRMATION  packet  can  only  be  interpreted  univer¬ 
sally  as  having  local  significance,  however  within  some 
Administration's  networks  clear  confirmation  may  have  end  to  end 
significance.  In  all  cases  the  time  spent  in  the  DTE  CLEAR 
REQUEST  state  (pR)  will  not  exceed  time-limit  T23  (see  Annex  4). 

It  is  possible  that  subsequent  to  transferring  a  CLEAR  REQUEST 
packet  the  DTE  will  receive  other  types  of  packets,  dependent  on 
the  state  of  the  loqical  channel,  before  receiving  a  DCE  CLEAR 
CONFIRMATION  packet. 

Note:  The  callinq  DTE  may  abort  a  call  by  clearing  it  before 

it  has  received  a  CALL  CONNECTED  or  CLEAR  INDICATION 
packet . 

The  called  DTE  may  refuse  an  incoming  call  by  clearing  it  as 
described  in  this  section  rather  than  transmitting  a  CALL 
ACCEPTED  packet  as  described  in  section  4.1.4. 

4.1.8  Clearing  by  the  DCE 

The  DCE  will  indicate  clearing  by  transferring  across  the  DTE/DCE 
interface  a  CLEAR  INDICATION  packet  (see  section  4.5).  The  logi¬ 
cal  channel  is  then  in  the  DCE  CLEAR  INDICATION  state  (p7).  The 
DTE  shall  respond  by  transferring  across  the  DTE/DCE  interface  a 
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DTP  CLEAR  CONFIRMATION  packet.  The  logical  channel  is  now  in  the 
READY  state  (pi ) . 

The  action  taken  by  the  DCE  when  the  DTE  does  not  confirm  clear¬ 
ing  within  time-out  Tl?  is  given  in  Annex  4. 

4.1.9  Clear  Coll ision 

Clear  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
trarsfer  a  CLEAR  REQUEST  packet  and  a  CLEAR  INDICATION  packet 
specifying  the  same  logical  channel.  Under  this  circumstance  the 
DCE  will  consider  that  the  clearing  is  completed.  The  DCE  will 
not  expect  a  DTE  CLEAR  CONFIRMATION  packet  and  will  not  transfer 
a  DCE  CLEAR  CONFIRMATION  packet.  This  places  the  logical  channel 
in  the  READY  state  (pi). 

4.1.10  Unsuccessful  Call 

If  a  call  cannot  be  established,  the  DCE  will  transfer  a  CLEAR 
INDICATION  packet  specifying  the  logical  channel  indicated  in  the 
CALL  REQUEST  packet. 

4.1.11  Call  Progress  Signals 

The  DCE  will  be  capable  of  transferring  to  the  DTE  clearing  call 
progress  signals  as  specified  in  Recommendation  X.96. 

Clearing  call  progress  signals  will  be  carried  in  CLEAR  INDICA¬ 
TION  packets  which  will  terminate  the  call  to  which  the  packet 
refers.  The  method  of  coding  CLEAR  INDICATION  packets  containing 
call  progress  signals  is  detailed  in  section  R.2.3. 

4.1.1?  Data  Transfer  State 

The  procedures  for  the  control  of  packets  between  DTE  and  DCE 
while  in  the  DATA  TRANSFER  state  are  contained  in  section  4.3, 

4,2  Procedures  for  Permanent  Virtual  Circuit  Service 

Annex  2,  Figures  A2.1/X.25  and  A2.3/X.25  show  the  state  diagrams 
which  give  a  definition  of  events  at  the  packet  level  DTE/DC E 
interface  for  logical  channels  assigned  for  permanent  virtual 
circuits. 

Annex  3  gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  2.  Details  of  the  action 
which  should  be  taken  by  the  DTE  are  for  further  study. 

For  permanent  virtual  circuits  there  is  no  call  set-up  or  clear¬ 
ing.  The  procedures  for  the  control  of  packets  between  DTE  and 
DCE  while  in  the  DATA  TRANSFER  state  are  contained  in  section 
4.3. 
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4  .  7  P  r  p  r  p  d  li  r  p  p__f  o  r  Data  and  Interrupt  Transfer 

Ti  e  data  ti  'npfer  and  interrupt  procedures  described  in  the  fol¬ 
lowing  subsrct  ions  apply  independently  to  each  logical  channel 
ar-si  ine<;  for  virtual  calls  or  a  permanent  virtual  circuit  exist¬ 
in'!  a*  the  DTE/DCE  interface. 

Normal  network  operation  dictates  that  user  data  in  data  and 
interrupt  packets  are  all  passed  transparently,  unaltered  through 
the  network  in  the  case  of  packet  DTE  to  packet  DTE  communica¬ 
tions.  Order  of  bits  in  data  packets  is  preserved.  Packet 
sequences  are  delivered  as  complete  packet  sequences.  DTE  Diag¬ 
nostic  Codes  are  treated  as  described  in  sections  P.2.3,  P.5.7 
and  P . P .  1 . 

4.3.1  States  for  Data  Transfer 

A  virtual  call  logical  channel  is  in  the  DATA  TRANSFER  state  (p4) 
after  completion  of  call  establishment  and  prior  to  a  clearing  or 
a  restart  procedure.  A  permanent  virtual  circuit  logical  channel 
is  continually  in  the  DATA  TRANSFER  state  ( p4 )  except  during  the 
restart  procedure.  Data,  interrupt,  flow  control  and  reset  pack¬ 
ets  may  be  transmitted  and  received  by  a  DTE  in  the  DATA  TRANSFER 
state  of  a  logical  channel  at  the  DTE/DCE  interface.  In  this 
stite,  the  flow  control  and  reset  procedures  described  in  section 
4.4  apply  to  data  transmission  on  that  logical  channel  to  and 
from  the  DTE. 

When  a  virtual  call  is  cleared,  data  and  interrupt  packets  may  be 
discarded  by  the  network  (see  section  4.5).  In  addition  data, 
interrupt,  flow  control  and  reset  packets  transmitted  by  a  DTE 
will  be  ignored  by  the  DCE  when  the  logical  channel  is  in  the  DCE 
CLEAR  INDICATION  state  ( p7 ) .  Hence  it  is  left  to  the  DTE  to 
define  DTE  to  DTE  protocols  able  to  cope  with  the  various  possi¬ 
ble  situations  that  may  occur. 

4.3.2  User  Data  Field  Length  of  Data  Packets 

The  standard  maximum  User  Data  field  length  Is  128  octets. 

In  addition,  other  maximum  User  Data  field  lengths  may  be  offered 
by  Administrations  from  the  following  lists  16,  32,  64,  256,  512 
and  1024  octets.  An  optional  maximum  User  Data  field  length  may 
be  selected  for  a  period  of  time  as  the  default  maximum  User  Data 
field  length  common  to  all  virtual  calls  at  the  DTE/DCE  interface 
(see  section  7.2.1).  A  value  other  than  the  default  may  be 
selected  for  a  period  of  time  for  each  permanent  virtual  circuit 
(see  section  7.2.1).  Negotiation  of  maximum  User  Data  field 
lengths  on  a  per  call  basis  may  be  made  with  the  Flow  Control 
Parameter  Negotiation  facility  (see  section  7.2.2). 

Th»  User  Data  field  of  data  packets  transmitted  by  a  DTE  or  DCE 
may  contain  any  number  of  bits  up  to  the  agreed  maximum. 


Note-:  At  present,  some  networks  require  the  User  Data  field  to 

contain  an  inteqra]  number  of  octets  (see  section  3,  Note 

D  . 

If  the  User  Data  field  in  a  data  packet  exceeds  the  locally  per¬ 
mitted  maximum  User  Data  field  lenqth,  then  the  DTE  will  reset 
the  virtual  call  or  permanent  virtual  circuit  with  the  resettinq 
cause  "Local  procedure  error*. 

4.3.3  Delivery  Confirmation  Bit 

The  setting  of  the  Delivery  Confirmation  bit  (D  bit)  is  used  to 
iniicate  whether  or  not  the  DTE  wishes  to  receive  an  end-to-end 
acknowledgment  of  delivery,  for  data  it  is  transmitting,  by  means 
of  the  packet  receive  sequence  number  P (R )  (see  section  4.4). 

Note  1:  The  use  of  the  D  bit  procedure  does  not  obviate  the  need 
for  a  higher  level  protocol  agreed  between  the  communi¬ 
cating  DTEs  which  may  be  used  with  or  without  the  D  bit 
procedure  to  recover  from  user  or  network  generated 
resets  and  clearings. 

Note  2;  After  January  1982,  the  D  bit  procedure  should  be  con- 

sidered  an  integral  part  of  this  Recommendation.  In  the 
interim  period,  the  D  bit  procedure  will  be  available  on 
some  Public  Data  Networks  and  between  some  pairs  of  Pub¬ 
lic  Data  Networks  on  a  bilateral  basis. 

During  the  interim  period.  Administrations  of  networks 
which  do  not  provide  the  D  bit  procedure  should  be  con¬ 
sulted  to  determine  whether  the  significance  of  P(R)  is 
a  local  updating  of  the  window  across  the  packet  level 
DTE/DCE  interface  or  conveys  an  end-to-end  acknowledge¬ 
ment  of  delivery  of  data. 

In  order  to  facilitate  the  orderly  introduction  of  the  D  bit  pro¬ 
cedures  in  DTEs  and  DOES,  the  following  mechanisms  are  provided. 

The  calling  DTE  can  ascertain  during  call  establishment  that  the 
D  hit  procedure  can  be  used  for  the  call  by  setting  bit  7  in  the 
General  Format  Identifier  of  the  CALL  REQUEST  packet  to  1  (see 
section  fi.1.1).  Every  network  or  part  of  international  network 
where  the  D  bit  procedure  is  available  will  pass  this  bit  tran¬ 
sparently.  If  the  remote  DTE  is  able  to  handle  the  D  bit  pro¬ 
cedure,  it  should  not  regard  this  bit  being  set  to  1  in  the 
INCOMING  CALL  packet  as  invalid. 

Likewise,  the  called  DTE  can  set  bit  7  in  the  General  Format 
Identifier  of  the  CALL  ACCEPTED  packet  to  1.  Every  network  or 
part  of  international  network  where  the  D  bit  is  available  will 
pass  this  bit  transparently.  If  the  calling  DTE  is  able  to  han¬ 
dle  the  D  bit  procedure,  it  should  not  regard  this  bit  being  set 
to  1  in  the  CALL  CONNECTED  packet  as  invalid. 


Tf  at  y  nrtwnk  a  1  o '■  i  the  path  does  not  support  the  D  hit  pro¬ 
cedure,  tf  1?  would  be  indicated  by  call  clearing  by  the  DCE  with 
a  cause  ir.  'i  -etino  "  1  ncompat  i  bl  e  destination"  and  the  diagnostic 
*  level  i1  kvht  fll  format  identifier"  or  by  any  other  means  to 
indicate  or-  invalid  general  format  identifier  at  a  DTE/DCE  inter¬ 
face  (see  Table  A d .  ) /X . 2F )  . 

The  use  by  the  PTEs  of  the  abovp  mechanism  in  the  CALL  REp'JEFT 
and  CALL  AcrFPTFP  packets  is  recommended  but  is  not  mandatory  for 
usinq  the  n  bit  procedure  during  the  virtual  call. 

If  a  P  bit  is  set  to  1  in  a  data  packet  on  a  virtual  call  or  per¬ 
manent  virtual  circuit  where  the  P  bit  is  not  available,  this 
will  be  indicated  to  both  PTEs  by  a  RESET  INDICATION  packet  with 
the  cause  "Incompatible  destination"  and  the  diagnostic  "Invalid 
general  format  identifier",  or  by  any  other  means  to  indicate  an 
invalid  qeneral  format  identifier  at  a  DTE/DCE  interface  (see 
Table  Ad.  \  /x  .  . 

4.3.*  More  Data  Mark 

If  a  PTE  or  P^F  wishes  to  indicate  a  sequence  of  more  than  one 
packet,  it  uses  a  More  Data  mark  ( M  bit)  as  defined  below. 

The  m  hit  can  be  s«t  tc  1  in  any  data  packet.  When  it  is  set  to 
1  in  a  full  data  packet  or  in  a  partially  full  data  packet  also 
carrying  the  D  bit  set  to  1,  it  indicates  that  more  data  is  to 
follow.  Recombination  with  the  following  data  packet  may  be  only 
performed  within  the  network  when  the  M  bit  is  set  to  1  in  a  full 
data  packet  which  also  has  the  D  bit  set  to  0. 

A  sequence  of  data  packets  with  every  M  bit  set  to  1  except  for 
the  last  one  will  be  delivered  as  a  sequence  of  data  packets  with 
the  M  bit  set  to  1  except  for  the  last  one  when  the  original 
packets  having  the  M  bit  set  to  1  are  either  full  (irrespective 
of  the  setting  of  the  D  bit)  or  partially  full  but  have  the  D  bit 
set  to  1. 

Two  categories  of  data  packets,  A  and  B,  have  been  defined  as 
shown  in  Table  4.1/X.25.  Table  4.1/X.25  also  illustrates  the 
network's  treatment  of  the  M  and  D  bits  at  both  ends  of  a  virtual 
call  or  permanent  virtual  circuit. 


TABLE  4.1/X.75 

DEFINITION  OF  TOO  CATEGORIES  OF  DATA  PACKETS 
AND  NETWORK  TREATMENT  OF  THE  M  and  D  BITS 


Data  Packet 

Bent  by 

Source  DTE 

Combining 

with 

Subsequent 
Packet(s)  is 
Performed  by 
the  Network 
when  Possible 

Data  Packet* 
Received  by 
Destination  DTE 

Category 

D 

Full 

M 

D 

B 

0  or  1 

0 

No 

No 

0 

0 

B 

0 

1 

No 

No 

0 

1 

B 

1 

1 

No 

No 

1 

1 

B 

n 

0 

ES 

No 

0 

0 

B 

n 

1 

19 

No 

n 

1 

A 

1 

n 

Yes 

Yes  (see  Note) 

l 

n 

B 

l 

l 

Yes 

No 

l 

l 

*  Refers  to  the  delivered  data  packet  whose  last  bit  of  user  data 
corresponds  to  the  last  bit  of  user  data,  if  any,  that  was 
present  in  the  data  packet  sent  by  the  source  DTE. 


Note :  If  the  data  packet  sent  by  the  source  DTE  is  combined  with 

other  packets,  up  to  and  includinq  a  cateqory  B  packet, 
the  M  and  D  bit  settinqs  in  the  data  packet  received  by 
the  destination  DTE  will  be  according  to  that  given  in  the 
two  right  hand  columns  for  the  last  data  pac,,nt  sent  by 
the  source  DTE  that  was  part  of  the  combination. 

4.3.5  Complete  Packet  Sequence 

A  complete  packet  sequence  is  defined  as  being  composed  of  a  sin¬ 
gle  category  B  packet  and  all  contiguous  preceeding  category  A 
packets  (if  anyl  .  Category  A  packets  have  the  exact  maximum  User 
Data  field  length  with  the  M  bit  set  to  1  and  the  D  bit  set  to  (1. 
All  other  data  packets  are  category  B  packets. 


When  transmitted  by  a  source  DTE,  a  complete  packet  sequence  is 
always  delivered  to  the  destination  DTE  as  a  single  complete 
packet  sequence. 


Thu-  ,  if  the  rerpiv  ini  end  has  a  !  sripr  maxinum  riats  f  i  o  1  r3  lenotf 
than  the  trananittim  pnri,  then  packpts  within  a  ronpleta  packet 
Fpqnpnrp  will  he  con  b i n  ed  within  the  network.  They  will  he 
>J  r  1  i  v  rr  >'  ir  a  corplete  packet,  sequence  where  each  packet,  except 
the  last  one,  has  the  ex;rt  maxinum  data  field  length,  the  M  hit 
set  to  1,  and  the  D  hit  set  to  0.  The  User  Data  field  of  the 
last  packet  of  the  sequence  may  have  less  than  the  maxinum  lenqth 
and  the  N  and  p  hits  are  set  as  described  in  Table  4.1/X.Pf. 

If  the  maxinum  data  field  length  is  the  same  at  both  ends,  then 
data  fields  of  data  packets  are  delivered  to  the  receiving  DTF 
exactly  as  they  have  been  received  by  the  network,  except  as  fol¬ 
lows.  If  a  full  packet  with  the  f*1  bit  set  to  1  and  the  D  bit  set 
to  P  is  followed  by  an  empty  packet,  then  the  two  packets  may  be 
merged  so  as  to  become  a  single  category  R  full  packet.  If  the 
last  packet  of  a  complete  packet  sequence  transmitted  by  the 
source  DTE  has  a  User  Data  field  less  than  the  maximum  length 
with  the  M  bit  set  to  1  and  the  D  bit  set  to  0,  then  the  last 
packet  of  the  complete  packet  sequence  delivered  to  the  receiving 
DTE  will  hav’  the  M  bit  set  to  0. 

If  the  receiving  end  has  a  smaller  maximum  data  field  length  than 
the  transmitting  end,  then  packets  will  be  segmented  within  the 
network,  and  the  M  and  D  bits  set  by  the  network  as  described  to 
maintain  complete  packet  sequences. 

4 . 3 . fi  Qua! i f  i  er  Bit 

A  complete  packet  sequence  may  be  on  one  of  two  levels.  If  a  DTE 
wishes  to  transmit  data  on  more  than  one  level,  it  uses  an  indi¬ 
cator  called  the  Qualifier  bit  <0  bit!. 

When  only  one  level  of  data  is  being  transmitted  on  a  logical 
channel,  the  Qualifier  bit  is  always  set  to  0.  If  two  levels  of 
data  are  being  transmitted,  the  transmitting  DTE  should  set  the 
Qualifier  bit  in  all  data  packets  of  a  complete  packet  sequence 
to  the  sane  value,  either  0  or  1.  A  complete  packet  sequence, 
which  is  transmitted  with  the  Qualifier  bit  set  to  the  same  value 
in  all  packets,  Is  delivered  by  the  network  as  a  complete  packet 
sequence  wi*-h  the  Qualifier  bit  set  in  all  packets  to  the  value 
assigned  by  the  transmitting  DTE. 

The  action  of  the  np' work  when  the  Qualifier  bit  is  not  set  to 
the  same  value  by  the  transmitting  DTE  within  a  complete  packet 
sequence  is  left  for  further  study. 

Recommendation  X.?°  gives  an  example  of  the  procedures  to  be  used 
when  the  Qualifier  hit  is  set  to  1. 

Packets  are  numbered  consecutively  (see  section  4. 4. 1.1)  regard¬ 
less  of  their  data  level. 
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4.3.7  Interrupt  Procedure 

The  interrupt  procedure  allows  a  DTE  to  transmit  data  to  the 
remote  PTE,  without  following  the  flow  control  procedure  applying 
to  data  packets  (see  section  4.4).  The  interrupt  procedure  can 
only  apply  in  the  FLOW  CONTROL  READY  state  (dl)  within  the  DATA 
TRANSFER  state  (p4 ) . 

The  interrupt  procedure  has  no  effect  on  the  transfer  and  flow 
control  procedures  applying  to  the  data  packets  on  the  virtual 
call  or  permanent  virtual  circuit. 

To  transmit  an  interrupt,  a  DTE  transfers  across  the  DTE/DCE 
interface  a  DTE  INTERRUPT  packet.  The  DTE  should  not  transmit  a 
second  DTE  INTERRUPT  packet  until  the  first  one  is  confirmed  with 
a  DCE  INTERRUPT  CONFIRMATION  packet  (see  Note  2  to  Table 
A3. 4 /X. 25).  The  DCE,  after  the  interrupt  procedure  is  completed 
at  t.te  remote  end,  will  confirm  the  receipt  of  the  interrupt  by 
transferring  a  DCE  INTERRUPT  CONFIRMATION  packet.  The  receipt  of 
a  DCE  INTERRUPT  CONFIRMATION  packet  indicates  that  the  interrupt 
has  been  confirmed  by  the  remote  DTE  by  means  of  a  DTE  INTERRUPT 
CONFIRMATION  packet. 

The  DCE  indicates  an  interrupt  from  the  remote  DTE  by  transfer¬ 
ring  across  the  DTE/DCE  interface  a  DCE  INTERRUPT  packet  contain¬ 
ing  the  same  data  field  as  in  the  DTE  INTERRUPT  packet  transmit¬ 
ted  by  the  remote  DTE.  A  DCE  INTERRUPT  packet  is  delivered  at  or 
before  the  point  in  the  stream  of  data  packets  at  which  the  DTE 
INTERRUPT  packet  was  generated.  The  DTE  will  confirm  the  receipt 
of  the  DCE  INTERRUPT  packet  by  transferring  a  DTE  INTERRUPT  CON¬ 
FIRMATION  packet  . 

4 . 4  Procedures  for  Flow  Control 

Th i s  subsection  only  applies  to  the  DATA  TRANSFER  state  (p4)  and 
specifies  the  procedures  covering  flow  control  of  data  packets 
and  reset  on  each  logical  channel  used  for  a  virtual  call  or  a 
permanent  virtual  circuit. 

t  4.4.1  Flow  Control 

t  At  the  DTE/DCF  interface  of  a  logical  channel  used  for  a  virtual 

call  or  permanent  virtual  circuit,  the  transmission  of  data  pack¬ 
ets  is  controlled  separately  for  each  direction  and  is  based  on 
authorizations  from  the  receiver. 

On  a  virtual  call  or  permanent  virtual  circuit,  flow  control  also 
allows  a  DTE  to  limit  the  rate  at  which  the  remote  DTE  can 
transmit  data  packets.  This  is  achieved  by  the  receiving  DTE 
,  coatrolling  the  rate  at  which  it  accepts  packets  across  the 

'  DTE/DCE  interface,  noting  that  there  is  a  network-dependent  limit 

on  the  number  of  data  packets  which  may  be  in  the  network  on  the 
virtual  call  or  permanent  virtual  circuit. 
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4  .  4  .  1 .  1  N urter inn  of  Data  Packets 

Each  data  packet  transmitted  at  the  DTE/DOE  interface  for  each 
direction  of  transmission  in  a  virtual  call  or  permanent  virtual 
circuit  is  sequentially  numbered. 

The  senuence  nurher inq  scheme  of  the  packets  is  performed  modulo 
8.  The  packet  sequence  numbers  cycle  through  the  entire  range  0 
to  n.  Some  Administrations  will  provide  the  Extended  Packet 
Sequence  Numbering  facility  (see  section  7.1.1)  which,  if 
selected,  provides  a  sequence  numbering  scheme  for  packets  being 
perrormed  modulo  128.  In  this  case,  packet  sequence  numbers 
cycle  through  the  entire  range  0  to  127.  The  packet  sequence 
numbering  scheme,  modulo  8  or  12P,  is  the  same  for  both  direc¬ 
tions  of  transmission  and  is  conmon  for  all  logical  channels  at 
the  DTE/DCF.  interface. 

Only  data  packets  contain  this  sequence  number  called  the  packet 
send  sequence  number  P  (S ) . 

The  first  data  packet  to  be  transmitted  across  the  DTE/DCE  inter¬ 
face  for  a  qiven  direction  of  data  transmission,  when  the  logical 
channel  has  just  entered  the  FL<">W  CONTROL  READY  state  (dl),  has  a 
packet  send  sequence  number  equal  to  0. 

4 . 4 . 1 . 2  Window  Description 

At  the  DTE/DCE  interface  of  a  logical  channel  used  for  a  virtual 
call  or  permanent  virtual  circuit  and  for  each  direction  of  data 
transmission,  a  window  is  defined  as  the  ordered  set  of  W  con¬ 
secutive  packet  send  sequence  numbers  of  the  data  packets  author¬ 
ized  to  cross  the  interface. 

The  lowest  sequence  number  in  the  window  is  referred  to  as  the 
lower  window  edge,  when  a  virtual  call  or  permanent  virtual  cir¬ 
cuit  at  the  DTE/DCE  interface  has  just  entered  the  FLOW  CONTROL 
READY  state  (dl),  the  window  related  to  each  direction  of  data 
transmission  has  a  lower  window  edge  equal  to  0. 

The  packet  send  sequence  number  of  the  first  data  packet  not 
authorized  to  cross  the  interface  is  the  value  of  the  lower  win¬ 
dow  edge  plus  W  (modulo  R,  or  128  when  extended). 

The  standard  window  size  W  is  2  for  each  direction  of  data 
transmission  at  the  DTE/DCE  interface.  In  addition,  other  window 
sizes  may  be  offered  by  Administrations.  An  optional  window  size 
may  be  selected  for  a  p«  iod  of  time  as  the  default  window  size 
common  to  all  virtual  calls  at  the  DTE/DCE  interface  (see  section 
7.1.2).  A  value  other  than  the  default  may  be  selected  for  a 
period  of  time  for  each  permanent  virtual  circuit  (see  section 
7.1.2).  Negotiation  of  window  sizes  on  a  per  call  basis  may  be 
made  with  the  Flow  Control  Parameter  Negotiation  facility  (see 
section  7.2.2)  . 
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4.4. 1.1  Flow  Control  Principles 

When  the  sequence  nunber  P(S)  of  the  next  packet  to  be  transmit¬ 
ted  by  the  DTP  is  within  the  window,  the  DCF  is  authorized  to 
transmit  this  data  packet  to  the  DTE.  When  the  sequence  number 
P (S )  of  the  next  data  packet  to  be  transmitted  by  the  DCF  is  out¬ 
side  of  the  window,  the  DCE  shall  not  transmit  a  data  packet  to 

the  DTF.  The  DTE  should  follow  the  same  procedure. 

When  the  sequence  number  P(R)  of  the  data  packet  received  by  the 
DCE  is  the  next  in  sequence  and  is  within  the  window,  the  DCF 
will  accept  this  data  packet.  A  received  data  packet  containing 

a  P(S)  that  is  out  of  sequence  (i.e.,  there  is  a  duplicate  or  a 

gap  in  the  P(S)  numbering),  outside  the  window,  or  not  equal  to  0 
for  the  first  data  packet  after  entering  the  FLOW  CONTROL  READY 
state  (dl)  is  considered  by  the  DCE  as  a  local  procedure  error. 
The  DCF'will  reset  the  virtual  call  or  permanent  virtual  circuit 
(see  section  4.4.3),  The  DTE  should  follow  the  same  procedure. 

Some  networks  do  not  invoke  the  error  procedure  on  receipt  of  a 
data  packet  containing  a  P(S)  that  is  out  of  sequence  but  is 
within  the  window.  These  networks  may  pass  on  such  packets  to 
the  remote  DTE  in  order  to  make  it  possible  for  the  local  DTE  to 
retransmit  packets  on  virtual  calls  or  permanent  virtual  circuits 
(within  the  national  network) . 

A  number  (modulo  8,  or  1 ?&  when  extended),  referred  to  as  a 
packet  receive  sequence  number  P(R),  conveys  across  the  DTE/DCE 
interface  information  from  the  receiver  for  the  transmission  of 
data  packets.  When  transmitted  across  the  DTE/DCE  interface,  a 
P (R )  becomes  the  lower  window  edge.  In  this  way,  additional  data 
packets  may  be  authorized  by  the  receiver  to  cross  the  DTE/DCE 
inter  face . 

The  packet  receive  sequence  number,  P(R),  is  conveyed  in  data, 
receive  ready  (RR)  and  receive  not  ready  (RNR)  packets. 

The  value  of  a  P (R )  received  by  the  DCE  must  be  within  the  range 
from  the  last  P (R )  received  by  the  DCE  up  to  and  includinq  the 
packet  send  sequence  number  of  the  next  data  packet  to  be 
transmitted  by  the  DCE.  Otherwise,  the  DCE  will  consider  the 
receipt  of  this  P(R)  as  a  procedure  error  and  will  reset  the  vir¬ 
tual  cal]  or  permanent  virtual  circuit.  The  DTE  should  follow 
the  same  procedure. 

The  receive  sequence  number  P(R)  is  less  than  or  equal  to  the 
sequence  number  of  the  next  expected  data  packet  and  implies  that 
the  DTE  or  DCE  transmitting  P(R)  has  accepted  jit  least  all  data 
packets  numbered  up  to  and  including  P  ( R )  —  1 . 


! 
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4 .  4 .  1 . 4  Delivery  Confirmation 

When  the  D  bit  is  set  to  0  in  a  data  packet  having  P(S)  =  p,  the 
significance  of  the  returned  PfR)  correspond  inn  to  that  data 
packet  fi.e.,  PfR)  _>  p+ 1  1  is  a  local  updating  of  the  window 
across  the  packet  level  interface  so  that  the  achievable 
thromhput  is  not  constrained  by  the  DTE-to-DTF.  round  trip  delay 
across  the  network  (r)  . 

When  the  D  bit  is  set  to  1  in  a  data  packet  having  PfR)  =  p,  the 
significance  of  the  returned  PfR)  corresponding  to  that  data 
packet  fi.e.,  PfR)  _>  p+11  is  an  indication  that  a  PfR)  has  been 
received  fron  the  remote  DTE  for  all  data  bits  in  the  data  packet 
in  which  the  D  bit  had  originally  been  set  to  1. 

Note  1 ;  A  DTE,  on  receiving  a  data  packet  with  the  D  bit  set  to 
1,  should  transmit  the  corresponding  PfR)  as  soon  as 
possible  in  order  to  avoid  the  possibility  of  deadlocks 
(e.q.,  without  waiting  for  further  data  packets).  A 
data,  RR  or  RNR  packet  may  be  used  to  convey  the  PfR) 
(see  Note  to  section  4. 4. 1.6).  Likewise,  the  DCE  is 
required  to  send  PfR)  to  the  DTE  as  soon  as  possible 
from  when  the  PfR)  is  received  from  the  remote  DTE. 

Note  2:  In  the  case  where  a  PfR)  for  a  data  packet  with  the  D 

bit  set  to  1  is  outstanding,  local  updating  of  the  win¬ 
dow  will  be  deferred  for  subsequent  data  packets  with 
the  D  bit  set  to  0.  Rome  networks  may  also  defer  updat¬ 
ing  the  window  for  previous  data  packets  (within  the 
window)  with  the  D  bit  set  to  0  until  the  corresponding 
PfR)  for  the  packet  with  the  outstanding  D  bit  set  to  1 
is  transmitted  to  the  DTE. 

Note  3:  PfR)  values  cor  respond inq  to  the  data  contained  in  data 
packets  with  the  D  bit  set  to  1  need  not  be  the  same  at 
the  DTE/DCE  interfaces  at  each  end  of  a  virtual  call  or 
a  permanent  virtual  circuit. 


4.4. 1.5  DTE  and  DCE  Receive  Ready  fRR)  Packets 


RR  packets  are  used  by  the  DTE  or  DCE  to  indicate  that  it  is 
ready  to  receive  the  W  data  packets  within  the  window  starting 
with  PfR),  where  PfR)  Is  indicated  in  the  RR  packet. 


4.4. 1.6  DTE  and  DCE  Receive  Not  Ready  (RNR)  Packets 


RNR  packets  are  used  by  the  DTE  or  DCE  to  indicate  a  temporary 
inability  to  accept  additional  data  packets  for  a  given  virtual 
call  or  permanent  virtual  circuit.  A  DTE  or  DCE  receiving  an  RNR 
packet  shall  stop  transmitting  data  packets  on  the  indicated  log¬ 
ical  channel,  but  the  window  is  updated  by  the  PfR)  value  of  the 
RNR  packet.  The  receive  not  ready  situation  indicated  by  the 
transmission  of  an  RNR  packet  is  cleared  by  the  transmission  in 
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the  samr  direction  of  an  RR  packet  or  by  a  reset  procedure  being 
initiated. 


The  transmission  of  an  RR  packet  after  an  RNR  packet  at  the 
packet  level  is  not  to  he  taken  as  a  demand  for  retransmission  of 
packets  which  have  already  been  transmitted. 

Note ;  The  RNR  packet  may  he  used  to  convey  across  the  DTE/DCE 
interface  the  P(R)  value  corresponding  to  a  data  packet 
which  had  the  D  bit  set  to  1  in  the  case  that  additional 
data  packets  cannot  be  accepted. 

4,4.2  Throughput  Characteristics  and  Throughput  Classes 


The  attainable  throughput  on  virtual  calls  and  permanent  virtual 
circuits  carried  at  the  DTE/DCE  interface  may  vary  due  to  the 
statistical  sharinq  of  transmission  and  switch  resources  and  is 
constrained  by: 


(i)  the  access  line  character istics,  local  window  size  and 
traffic  char ac ter  i  st i cs  of  other  logical  channels  at 
the  local  PTF./DCE  interface, 


(ii)  the  access  line  cha r acter i st i cs ,  local  window  size  and 
traffic  char ac ter  i  st i cs  of  other  logical  channels  at 
the  remote  DTE/DCE  interface,  and 


(iii)  the  throughput  achievable  on  the  virtual  call  or  per- 
nanept  virtual  circuit  through  the  network(s)  indepen¬ 
dent  of  interface  char acter i st i cs  including  number  of 
aaftive  logical  channels.  This  throughput  may  be  depen¬ 
dent  on  network  service  characteristics  such  as  window 
^rotation  mechanisms  and/or  optional  user  facilities 
requested  on  national/internat ional  calls. 


The  attainable  throughput  will  also  be  affected  by: 


(i)  the  receiving  DTE  flow  controlling  the  DCE, 

(ii)  the  transmitting  DTE  not  sending  data  packets  which 
have  the  maximum  data  field  length, 

(iii)  the  local  DTE/DCE  window  and/or  packet  sizes,  and 

(iv)  the  use  of  the  D  bit. 


A  throughput  class  for  one  direction  of  transmission  is  an 
inherent  characteristic  of  the  virtual  call  or  permanent  virtual 
circuit  related  to  the  amount  of  resources  allocated  to  this  vir¬ 
tual  call  or  permanent  virtual  circuit.  This  characteristic  is 
meaningful  when  the  D  bit  is  set  to  0  in  data  packets.  It  is  a 
measure  of  the  throughput  that  is  not  normally  exceeded  on  the 
virtual  call  or  permanent  virtual  circuit.  However,  due  to  the 
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statistical  sharinq  of  transmission  ?nH  switchi'.o  resources,  it 
is  not.  guaranteed  ttiat  the  throughput  class  can  be  reached  lf,nt 
o  f  the  tine . 

Depending  on  the  network  and  the  applicable  conditions  at  the 
considered  moment,  the  effective  throughput  may  excooJ  the 
thro  ug  hpu t  cl  ass . 

Note:  The  definition  of  throughput  class  as  a  qrade  of  service 

parameter  is  for  further  study.  The  grade  of  service 
might  he  specified  when  the  D  bit  is  set  to  0  or  over  a 
time  period  between  the  completion  and  initiation  of  suc¬ 
cessive  D  bit  procedures. 

The  throughput  class  may  only  be  reached  if  the  following  condi¬ 
tions  are  met: 

(a)  the  access  data  links  of  both  ends  of  a  virtual  call  or 
permanent  virtual  circuit  are  engineered  for  the 
throughput  class; 

(b)  the  receiving  DTE  is  not  flow  controlling  the  DCE  such 
that  the  throughput  class  is  not  reachable; 

(c)  the  transmitting  DTE  is  sending  data  packets  which  have 
the  maximum  data  field  length;  and 

(d)  all  data  packets  transmitted  on  the  virtual  call  or 
permanent  virtual  circuit  have  the  D  bit  set  to  0. 

The  throughput  class  is  expressed  in  bits  per  second.  At  a 
DTE/DCE  interface,  the  maximum  data  field  length  is  specified  for 
a  virtual  call  or  permanent  virtual  circuit,  and  thus  the 
throughput  class  can  be  interpreted  by  the  DTE  as  the  number  of 
full  data  packets/second  that  the  DTE  does  not  have  a  need  to 
exceed  . 

In  the  absence  of  the  Default  Throughput  Class  Assignment  facil- 
tiy  (see  section  7.1.3),  the  default  throughput  classes  for  both 
directions  of  transmission  correspond  to  the  user  class  of  ser¬ 
vice  of  the  DTE  (see  section  7.4, 2.6)  but  do  not  exceed  the  max¬ 
imum  throughput  class  supported  by  the  network.  Negotiation  of 
throughput  classes  on  a  per  call  basis  may  be  made  with  the 
Throughput  Class  Negotiation  facility  (see  section  7.2.3). 

Note :  The  summation  of  throughput  classes  of  all  virtual  calls, 

permanent  virtual  circuits  and  datagram  logical  channels 
supported  at  a  DTE/DCE  interface  may  be  greater  than  the 
data  transmission  rate  of  the  access  line. 
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4 .  A  .  3  Procedure  for  Reset 

The  reset  procedure  is  used  to  r  e- i  n  i  t  i  a  1  i  ze  the  virtual  call  or 
permanent  virtual  circuit  and  in  so  doing  removes  in  each  direc¬ 
tion  all  data  and  interrupt  packets  which  may  be  in  the  network 
(se.-  section  4.5).  When  a  virtual  call  or  permanent  virtual  cir¬ 
cuit  at  the  DTE/DCF  interface  has  just  been  reset,  the  window 
related  to  each  direction  of  data  transmission  has  a  lower  window 
edge  equal  to  0,  and  the  numbering  of  subsequent  data  packets  to 
cross  the  DTE/DCE  interface  for  each  direction  of  data  transmis¬ 
sion  shall  start  from  0. 

The  reset  procedure  can  only  apply  in  the  DATA  TRANSFER  state 
(p4)  of  the  PTE/DCE  interface.  In  any  other  state  of  the  DTE/DCF 
interface,  the  reset  procedure  is  abandoned.  For  example,  when  a 
clearing  or  restarting  procedure  is  initiated,  RESET  REQUEST  and 
RESET  INDICATION  packets  can  be  left  unconfirmed. 

For  flow  control,  there  are  three  states  dl,  d2  and  d3  within  the 
DATA  TRANSFER  state  (p4).  They  are  FLOW  CONTROL  READY  (dl )  ,  DTE 
RESET  REQUEST  (d?),  and  DOE  RESET  INDICATION  fd3 )  as  shown  in  the 
state  diagram  in  Annex  2,  Figure  A2.3/X.25.  When  entering  state 
p4 ,  the  logical  channel  is  placed  in  state  dl.  Annex  3,  Table 
A3. 4 /X . 25  specifies  actions  taken  by  the  DCE  on  the  receipt  of 
packets  from  the  DTE. 

4. 4. 3.1  Reset  Request  Packet 

The  DTE  shall  indicate  a  request  for  reset  by  transmitting  a 
RESET  REQUEST  packet  specifying  the  logical  channel.  This  places 
the  logical  channel  in  the  DTE  RESET  REQUEST  state  (d2). 

4. 4. 2. 2  Reset  Indication  Packet 

The  DCE  shall  indicate  a  reset  by  transmitting  to  the  DTE  a  RESET 
INDICATION  packet  specifying  the  logical  channel  and  the  reason 
for  the  resetting.  This  places  the  logical  channel  in  the  DCE 
RESET  INDICATION  state  (d3).  In  this  state,  the  DCE  will  ignore 
data,  interrupt,  RR  and  RNR  packets. 

4. 4. 3. 3  Reset  Collision 

Reset  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
transmit  a  RESET  REQUEST  packet  and  a  RESET  INDICATION  packet 
specifying  the  same  logical  channel.  Under  this  circumstance  the 
DCE  will  consider  that  the  reset  is  completed.  The  DCE  will  not 
expect  a  DTE  RESET  CONFIRMATION  packet  and  will  not  transfer  a 
DCE  RFSFT  CONFIRMATION  packet.  This  places  the  logical  channel 
in  the  FLOW  CONTROL  READY  state  (dl). 
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4.4.T.4  Reset  Confirmation  Packets 


When  the  logical  channel  in  in  the  DTF  RESET  REOUEST  state  (d?), 
the  PCE  will  confirm  reset  by  transmitting  to  the  PTE  a  DCF  RESET 

C  ON  F  I RM  AT  T  PK  packet.  This  places  the  logical  channel  in  the  FL°'' 

CONTROL  READY  state  (HI). 

The  P"E  RF^ET  CONFTRVATIO"  packet  can  only  he  interpreted  univer¬ 
sally  as  havinq  local  significance,  however  within  some 
Administration's  networks  reset  confirmation  may  have  end  to  end 
significance.  In  all  cases  the  time  spent  in  the  DTE  RESET 

R  F,  O' IE  ST  state  (d?)  will  not  exceed  time-limit  TP?  (see  Annex  4). 

When  the  logical  channel  is  in  the  PCE  RESET  INDICATION  state 
(d?),  the  PTE  will  confirm  reset  by  transmitting  to  the  DCE  a  PTE 
RESET  CONFIRMATION  packet.  This  places  the  logical  channel  in 
the  FLOW  CONTROL  READY  state  (dl).  The  action  taken  by  the  DCE 
when  the  DTE  does  not  confirm  the  reset  within  time-out  T12  is 
given  in  Annex  4. 

4 . 5  Effects  of  Clear,  Reset  and  Restart  Procedures  on  the 
Transfer  of  Packets 


All  data  and  interrupt  packets  generated  by  a  DTE  (or  the  net¬ 
work)  before  initiation  by  the  DTE  or  the  DCE  of  a  clear,  reset 
or  restart  procedure  at  the  local  interface  will  either  be 
delivered  to  the  remote  DTE  before  the  DCE  transmits  the 
corresponding  indication  on  the  remote  interface,  or  be  discarded 
by  the  network . 

No  data  or  interrupt  packets  generated  by  a  DTE  (or  the  network) 
after  the  completion  of  a  reset  (or  for  permanent  virtual  cir¬ 
cuits  also  a  restart)  procedure  at  the  local  interface  will  be 
delivered  to  the  remote  DTE  before  the  completion  of  the 
corresponding  reset  procedure  at  the  remote  interface. 

When  a  DTE  initiates  a  clear,  reset  or  restart  procedure  on  its 
local  interface,  all  data  and  interrupt  packets  which  were  gen¬ 
erated  by  the  remote  DTE  (or  the  network)  before  the  correspond¬ 
ing  indication  is  transmitted  to  the  remote  DTE  will  be  either 
delivered  to  the  initiating  DTE  before  DCE  confirmation  of  the 
initial  clear,  reset  or  restart  request,  or  be  discarded  by  the 
network . 

Note ;  The  maximum  number  of  packets  which  may  be  discarded  is  a 
function  of  network  end-to-end  delay  and  throughput 
char acter i st i cs  and,  in  general,  has  no  relation  to  the 
local  window  size.  Provision  of  more  precise  information 
is  for  further  study.  For  virtual  calls  and  permanent 
virtual  circuits  on  which  all  data  packets  are  transferred 
with  the  D  bit  set  to  1,  the  maximum  number  of  packets 
which  may  be  discarded  in  one  direction  of  transmission  is 
not  larger  than  the  window  size  of  the  direction  of 
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transmission. 

& •  Effects  of  Physical  and  Link  Level  Failures 

When  a  failure  on  the  physical  and/or  link  level  is  detected,  the 
DCE  will  transmit  to  the  remote  end: 

(1)  a  reset  with  the  cause  "Out  of  order"  for  each  permanent 
virtual  circuit  and 

(2)  a  clear  with  the  cause  "Out  of  order"  for  each  existing 
virtual  call. 

During  the  failure,  the  DCE  will  clear  any  incoming  virtual 
calls. 

When  the  failure  is  recovered  on  the  physical  and  link  levels, 
the  restart  procedure  will  be  actioned  (see  section  3.5)  and  a 
reset  with  the  cause  "Remote  DTE  operational"  will  be  transmitted 
to  the  remote  end  of  each  permanent  virtual  circuit. 


5.  PROCEDURES  FOR  DATAGRAM  SERVICE 

Annex  2  shows  the  state  diagrams  which  give  a  definition  of 
events  at  the  packet  level  DTE/DCE  interface  for  each  logical 
channel.  Figures  A2.1/X.25  and  A2.3/X.25  apply  to  datagram  logi¬ 
cal  channels. 

Annex  3  gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  2.  Details  of  actions 
which  should  be  taken  by  the  DTE  are  for  further  study. 

There  is  no  call  set-up  or  clearing  for  datagrams. 

A  DTE  DATAGRAM  packet  includes  the  destination  DTE  address;  the 
source  DTE  address  may  also  be  used. 

A  DCE  DATAGRAM  packet  includes  the  source  DTE  address;  the  desti¬ 
nation  DTE  address  may  also  be  used. 

Note :  A  DTE  address  may  be  a  DTE  network  address,  an  abbreviated 
address  or  any  other  DTE  identification  agreed  for  a  period 
of  time  between  the  DTE  and  the  DCE. 

5.  1  Procedures  for  Datagram  Transfer 

The  data  transfer  proujdure  applies  independently  to  each 
datagram  logical  channel  existing  at  the  DTE/DCE  interface. 

Normal  network  operation  dictates  that  user  data  in  datagram 
packets  are  all  passed  transparently,  unaltered  through  the  net¬ 
work  in  the  case  of  packet  DTE  to  packet  DTE  communications. 
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freer  of  hits  of  user  data  is  pr  pscrvrd  within  a  dataoran. 

5.1.1  States  for  Data  Transfer 

Dataqran  logical  channels  are  continually  in  the  DATA  TRANSFER 
state  (pO  except  during  the  restart  procedure.  Datagram, 
datagram  sorvicr  sianal,  flow  control,  and  reset  packets  nay  he 
transnitted  and  received  by  a  PTF  in  the  DATA  TRANSFER  state  of  a 
dataqran  logical  channel  at  the  PTE/P^E  interface.  In  this 
state,  the  flow  control  and  reset  procedures  described  in  section 
R.?  apply  to  data  transnission  on  that  detagran  logical  channel 
to  and  fron  the  PTE . 

5.3.2  User  Data  Field  Length 

The  maximum  User  Data  field  length  for  datagrams  is  1?P  octets. 

The  data  field  of  datagram  packets  transmitted  by  a  DTE  or  DCF 
may  contain  any  number  of  bits  up  to  the  maximum. 

Note:  At  present,  some  networks  require  the  data  field  to  con¬ 

tain  an  integral  number  of  octets  (see  section  3,  Note  2). 

5.1.3  Datagram  I  dent i f i cat  1  on 

Each  datagram  transmitted  at  the  DTE/DCE  interface  for  each 
direction  of  transmission  may  be  uniquely  numbered  with  a 
datagram  identification  number.  Assignment  of  the  values  to  the 
datagram  identification  is  a  DTE  responsibility  and  may  be 
assigned  according  to  any  algorithm.  The  network  will  not 
operate  on  the  datagram  identification  except  to  return  the 
information  in  the  appropriate  network  generated  datagram  service 
signal  packet. 

5.1.4  Datagram  Service  Signals 

The  DCE  will  be  capable  of  transferring  to  the  DTE  service  sig¬ 
nals  as  specified  in  Recommendation  X.96.  The  datagram  service 
signals  will  be  carried  in  datagram  service  signal  packets. 
Dataqran  service  signals  are  of  two  types  -  specific  and  general. 

5. 1.4.1  Datagram  Service  Signal  -  Specific 

This  is  a  service  siqnal  generated  by  the  network  relative  to  a 
specific  datagram  issued  by  the  DTE.  There  are  three  classes  for 
this  type  of  service  signal: 

(a)  Datagram  rejected  -  datagram  discarded  by  network;  a 
correction,  based  on  the  received  cause,  is  required 
before  trying  again. 

(b)  Datagram  non-del i very  indication  -  datagram  discarded 
by  network;  try  again  later  based  on  the  received 
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cause,  next  time  may  he  successful. 

Note :  This  class  of  service  signal  is  only  issued  by 

the  network  when  the  non-riel ivery  indication 
facility  (see  section  7.3.4)  has  been  requested. 

I c)  Patan  rar  del ivery  ronf i rmat i on  -  datagram  bar  bee- 
accepted  by  the  destination  PTE. 

Note :  This  class  of  service  signal  is  only  issued  by 

the  network  when  the  delivery  confirmation 
faei’ity  fsep  section  7.3.5)  has  been  requested. 

Datagram  service  signal  -  specific  packets  will  include  the 
address  information,  if  valid,  and  the  datagram  identification 
associated  with  the  original  datagram  for  which  the  service  sig¬ 
nal  applies.  The  original  destination  address  is  provided  in  the 
datagram  service  signal  packet  as  the  source  address  while  the 
original  source  address  is  shown  as  the  destination  address,  when 
present . 

5 . 1 . 4 . 2  Datagram  Service  Signal  -  General 

This  is  a  service  signal  generated  by  the  network  relative  to 
datagram  operation  but  not  to  any  specific  dataqram  issued  by  the 
DTE. 

5. 2  Procedures  for  Flow  Control 

This  subsection  only  applies  to  the  D*\TA  TR^NFFFR  state  ( p-*  1  and 
specifies  the  procedures  covering  flow  control  of  dataqram  anJ 
datagram  service  signal  packets  and  reset  on  each  dataqram  logi¬ 
cal  channel  . 

5. 2.  1  Flow  Cont  rol 

At  the  DTE/DCE  interface  of  a  datagram  logical  channel,  the 
transmission  of  datagram  and  dataqram  service  si  .  •  '  rackets  is 
controlled  separately  for  each  direction  and  is  based  hori- 

zatiors  from  the  receiver.  Datagram  and  datagram  service  signal 
packets  are  referred  to  below  as  flow  controlled  packets. 

5 . 2 . 1 . 1  Numbering  of  Packets 

Each  dataqram  and  dataqram  service  signal  packet  transmitted  at 
the  PTE/D^F  interface  for  each  direction  of  transmission  on  a 
give-  datagram  logical  channel  is  sequentially  numbered. 

The  sequence  numberim  scheme  of  the  packets  is  per  forr,pJ  modulo 
P.  The  packet  sequence  numbers  cycle  through  the  entire  range  0 
to  7 .  Some  Administrations  will  provide  the  Extended  Packet 
Sequence  Numbering  facility  (see  section  .  1 .  1  )  which,  if 
selected,  provides  a  sequence  numbering  scheme  for  packets  being 
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•  -  >•  '  .  '  T  •  .  Ir,  this  riif  ,  packet  sequence  number.1 

•  1  -  ■  • 1  •  •  ■  ■  e •  r  i r  «  t  a n i e  n  to  1  2  7 .  The  picket  s^cjnrcr 

•  '  ■  !  s  -  >  (  i-i  ■  ■  1 1 !  !  -I  0  or  1  ?r  ,  i  r  the  sane  for  both  <*  i  r  e  c 

*  r  >  •  '  "  i c  ■  i  •  ■  r-  a  ’•  :  isc  on  non  for  all  logical  channel  r. 


!■•••»  '•  i  •»  ,  on'  v  d  eta  i  ran  and  datagram  service  sin  pa  I 
•  in  t v  i  <•  se’ii-'nr'i'  number  called  the  packet  sen-1 
■  :  •  •  !  ■  '  . 


’  e  f  t  r  •  f  1  ,•  t  a  i  r  v"  rt  d  •  t  ug  r  an  service  signal  packet  to  be 

*  r  ■■  ;  *  t  i  '  a  -  r  '  r-  t  h  «>  Pt  f  /P~E  interface  for  a  given  d  i  r  e "  *.  i  o  r  of 

*  t  .  i  i  •  ,  w»n  t v  e  d  a  t  ag  r  am  1  og  i  c  a  1  rhann  •  •  1  has  just 

•  » *  .  c  !  '  rr»v  r»<r*|  READY  state  (  d  1  )  ,  has  a  packet  send 

r-  ’  e  r  e  ( i  ‘  i  a  1  r  o  n  . 


k  ;  r  U  w  he  s  c  r  i  t  t  i on 


'  :  ritru  fact  of  a  datagram  loqical  channel,  and  for 

'  *  1  't  ?  transmission,  a  window  is  defined  as  the 

‘  v  ,rr-  e~-.it  ive  packet  send  sequence  numbers  of  the 
►  p  ■»  ■  k  ■  ■  t  r  authorized  to  cross  the  interface. 


■  e  number  in  the  window  is  referred  to  as  the 
•  *  <  .  wneri  the  datagram  logical  channel  has  just 

?!  1  •.  >»>7K  ■'[  ready  state  (dll,  the  window  related  to 

‘  !  ->  t  a  transmission  has  a  lower  window  edoe  equal 


■-•"i  •  s *»uuence  number  of  the  first  flow  controlled 

-■  ‘  •  >  1 1*  1  r  i  zed  to  cross  the  interface  is  the  value  of  the 

-  •  -  "'ip  plus  w  (modulo  9,  or  129  when  extended). 

•  1  window  s  i  .  c  w  is  2  for  each  direction  of  data 

•  r  ’  •  -c  t ...  at  a  RTF /P"F  interface.  In  addition,  other  window 
•  offer^a  py  Administrations  and  may  be  selected  for  a 

!•*'  •>  ‘  *  •  m  e  for  each  da  tag  ram  logical  channel  (see  section 


l  i'w  f'ontro  ]  Principles 

>  ■  *  ■  nc , me n c e  n um her  of  the  next  flow  controlled  packet  to  be 

•  ’  *  t  <’  i  by  the  P^F  is  within  the  window,  the  DCF  is  author- 

*  •  'ra.  .-it  this  flow  controlled  packet  to  the  DTE.  When 

•'  ■■  "imr, -<•>  number  P  fr. )  of  the  next  flow  controlled  packet  to  be 
■  -  •  >  ■  -  c  !  by  the  pep  j  ri  outside  of  the  window,  the  DCE  shall 

t  • r  ■  ■  sm i t  a  flow  controlled  packet  to  the  DTE.  The  DTE  should 

'  •'  \  I  ’w  t  fie  same  procedure. 

wu..r  t  v, ..  ccquoncp  numher  P  (S  )  of  the  flow  controlled  packet 
•er-.'i--.  >  by  the  per  i  s  the  next  in  sequence  and  is  within  the 
pl(,  prp  will  accept  this  flow  controlled  packet.  A 
•  e- « *>.,w  controlled  packet  containinq  a  P(P)  that  is  out  of 
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sequence  (i.e.,  there  is  a  duplicate  or  a  gap  in  the  P(E)  number¬ 
ing),  outside  the  window,  or  not  equal  to  zero  for  the  first  flow 
controlled  packet  after  enterinq  the  FLOW  CONTROL  READY  state 
(dl)  is  considered  by  the  DOE  as  a  local  procedure  error.  The 
DOE  will  reset  the  datagram  logical  channel  (see  section  5.2,3). 
The  DTE  should  follow  the  same  procedure. 

A  number  (modulo  P,  or  1 ?P  when  extended)  ,  referred  to  as  a 
packet  receive  sequence  number  P(R),  conveys  across  the  DTE/DCE 
interface  information  from  the  receiver  for  the  transmission  of 
flow  controlled  packets.  When  transmitted  across  the  DTE/DCE 
interface,  a  P(R)  becomes  the  lower  window  edge.  In  this  way, 
additional  flow  controlled  packets  may  be  authorized  by  the 
receiver  to  cross  the  DTE/DCE  interface. 

The  packet  receive  sequence  number,  P(R),  is  conveyed  in 
datagram,  datagram  service  signal,  receive  ready  (RR)  and  receive 
not  ready  (RNR)  packets. 

The  value  of  a  P(R)  received  by  the  DCE  must  be  within  the  ranqe 
from  the  last  P(R)  received  by  the  DCE  up  to  and  including  the 
packet  send  sequence  number  of  the  next  flow  controlled  packet  to 
be  transmitted  by  the  DCE.  Otherwise,  the  DCE  will  consider  the 
receipt  of  this  P(R)  as  a  procedure  error  and  will  reset  the  log¬ 
ical  channel.  The  DTE  should  follow  the  same  procedure. 

The  receive  sequence  number  P(R)  is  less  than  or  equal  to  the 
sequence  number  of  the  next  expected  flow  controlled  packet  and 
implies  that  the  DTE  or  DCE  transmitting  P(R)  has  accepted  at 
least  all  flow  controlled  packets  numbered  up  to  and  including 
P(R)-1. 

The  only  significance  of  a  P  (R )  value  is  a  local  updating  of  the 
window  across  the  packet  level  interface. 

5. 2. 1.4  Datagram  Queue 

The  network  maintains  a  datagram  queue  for  each  datagram  logical 
channel  at  destination  DCE.  The  maximum  length  of  the  queue  for 
each  datagram  logical  channel  is  agreed  for  a  period  ot  ti.. 
between  the  DTE  and  the  Administration  (see  section  7.3.2). 

Datagram  service  signal  packets  have  priority  over  other  datagram 
packets  and  are  inserted  at  the  beginning  of  the  queue.  This  may 
lead  to  the  DCE  discarding  the  last  datagram  packet  of  the  queue 
if  the  maximum  queue  length  is  exceeded.  When  the  queue  is  full, 
additional  arriving  datagrams  are  discarded. 

By  agreement  for  a  period  of  time  between  the  DTE  and  the 
Administration  (see  section  7.3.3),  a  special  datagram  logical 
channel  may  be  assigned  for  the  transmission  of  datagram  service 
signals,  In  this  case,  the  maximum  length  of  the  queues  for 
datagrams  and  datagram  service  signals  are  independently  agreed 


between  the  PTE  and  the  Administration. 

If  the  PTf  flow  controls  the  receipt  of  datagram  service  signal 
packets,  the  P"F  cannot  quarantee  to  store  an  indefinite  number 
of  service  sinnals.  Therefore,  there  is  a  possibility  of  loss  of 
service  siqnal  packets  at  the  P"E.  A  possible  couplinq  nechanisn 
to  allow  the  P" P  to  regulate  the  number  of  dataqrans  generated  by 
the  PTP  in  relation  to  the  capacity  of  the  DCF,  to  store  the 
datagram  service  siqnals  will  be  studied  to  determine  whether 
such  losses  at  the  P^E  should  be  prevented. 

S.2.1.P  PTE  and  DCE  Receive  Ready  (RR )  Packets 

RR  packets  are  used  by  the  DTE  or  DCE  to  indicate  that  it  is 
ready  to  receive  the  W  flow  controlled  packets  within  the  window 
starting  with  P(R),  where  P  (R  )  is  indicated  in  the  RR  packet. 

5 . 2 . 1 . 6  DTE _ and  DCE  Receive  Not  Ready  (RNR)  Packets 

RNR  packets  are  used  by  the  DTE  or  DCE  to  indicate  a  temporary 
inability  to  accept  additional  flow  controlled  packets  for  a 
given  dataqram  logical  channel .  A  DTE  or  DCE  receiving  an  RNR 
packet  shall  stop  transmitting  flow  controlled  packets  on  the 
indicated  datagram  logical  channel,  but  the  window  is  updated  by 
the  P fR )  value  of  the  RNR  packet.  The  receive  not  ready  situa¬ 
tion  indicated  by  the  transmission  of  RNR  packet  is  cleared  by 
the  transmission  in  the  same  direction  of  an  RR  packet  or  by  a 
reset  procedure  being  initiated. 

The  transmission  of  an  RR  after  an  RNR  at  the  packet  level  is  not 
to  he  taken  as  a  demand  for  retransmission  of  packets  which  have 
already  been  transmitted. 

f.2.2  Throughput  Characteristics 

Throughput  is  the  effective  data  transfer  rate  measured  in  bits 
pe r  second  . 

For  each  datagram  logical  channel  ,  a  throughput  class  for  each 
direction  of  data  transmission  at  the  DTE/DCE  interface  is  agreed 
for  a  period  of  time  between  the  DTE  and  the  Administration  (see 
sect  ion  7.1.3). 

Relating  to  datagram  operation,  the  following  has  been  identified 
for  further  study: 

(a)  The  attainment  of  throughput  on  a  given  datagram  logi¬ 
cal  channel  . 

(b)  The  necessity  for  d i sc r im i nat i ng  between  throughput  on 
datagram  loqical  channels  compared  with  logical  chan¬ 
nels  used  for  virtual  calls  and  permanent  virtual  cir¬ 
cuits. 


-  61 


5 . 2 . 3  Procedure  for  Reset 

The  reset  procedure  is  used  to  r e- i n i t i a  1  i  ze  the  dataqram  logics] 
channel.  When  a  datagram  logical  channel  at  the  DTE/DOE  inter¬ 
face  has  just  been  reset,  the  window  related  to  each  direction  of 
data  transmission  has  a  lower  window  edge  equal  to  0,  and  the 
numbering  of  subsequent  flow  controlled  packets  to  cross  the 
DTE/DCE  interface  for  each  direction  of  data  transmission  shall 
start  from  0. 

For  datagram  logical  channels,  the  reset  procedure  causes 
datagrams  and  datagram  service  signals  to  be  purged  from  the  DCE 
queue  associated  with  that  datagram  logical  channel.  A  datagram 
service  signal  with  the  cause  "Remote  procedure  error"  will  be 
issued  to  the  remote  end  for  each  datagram  requesting  the  non¬ 
delivery  indication  facility. 

The  reset  procedure  can  only  apply  in  the  DATA  TRANSFER  state 
( p 4 )  rf  the  DTE/DCE  Interface.  In  any  other  state  of  the  DTE/DCE 
interface,  the  reset  procedure  is  abandoned.  For  example,  when  a 
restarting  procedure  is  initiated,  RESET  REQUEST  and  RESET  INDI¬ 
CATION  packets  can  be  left  unconfirmed. 

For  flow  control,  there  are  three  states  dl,  d2,  and  d3  within 
the  DATA  TRANSFER  state  ( p4 ) .  They  are  FLOW  CONTROL  READY  (dl ) , 
DTE  RESET  REQUEST  (d2),  and  DCE  RESET  INDICATION  (d3)  as  shown  in 
the  state  diagram  in  Annex  2,  Figure  A2.3/X.25.  When  entering 
state  p4,  the  datagram  logics!  channel  is  placed  in  state  dl. 
Annex  3,  Table  A3.4/X.25  specifies  actions  taken  by  the  DCE  on 
the  receipt  of  packets  from  the  DTE. 

5. 2. 3.1  Reset  Request  Packet 

The  DTE  shall  indicate  a  request  for  reset  by  transmitting  a 
RESET  REQUEST  packet  specifying  the  datagram  logical  channel. 

This  places  the  datagram  logical  channel  in  the  DTE  RESET  REQUEST 
state  (d2 ) . 

5. 2. 3. 2  Reset  Indication  Packet 

The  DCE  shall  indicate  a  reset  by  transmitting  to  the  DTE  a  RESET 
INDICATION  packet  specifying  the  datagram  logical  channel  and  the 
reason  for  the  resetting.  This  places  the  datagram  logical  chan¬ 
nel  in  the  DCE  RESET  INDICATION  state  ( d 3 ) .  In  this  state,  the 
DCE  will  ignore  datagram,  RR  and  RNR  packets. 

5. 2. 3. 3  Reset  Collision 

Reset  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
transmit  a  RESET  REQUEST  packet  and  a  RESET  INDICATION  packet 
specifying  the  same  datagram  logical  channel.  Under  this  cir¬ 
cumstance,  the  DCE  will  consider  the  reset  completed.  The  DCE 
will  not  expect  a  DTE  RESET  CONFIRMATION  packet  and  will  not 
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1 1  anr  f  er  a  DCE  HFRET  CONFIRMATION  packet.  This  places  the 
datagram  loqical  channel  in  the  FLOW  CONTROL  READY  state  (dl). 


5 .  2 .  3 .  4  Res  e_t_  C  o  n  f  i  r  oat  ion  Packets 

When  the  da tag  ran  logical  channel  is  in  the  DTE  RESET  REQUEST 
state  (c’2),  the  DCE  will  confirm  reset  by  transmitting  to  the  DTE 
a  DCF  RESET  CONFIRMATION  packet.  This  places  the  datagram  logi¬ 
cal  channel  in  the  FLOW  CONTROL  READY  state  (dl). 


The  DCF  R Ec FT  CONFIRMATION  packet  has  local  significance.  The 
tine  spent  in  the  PTE  RESET  REQUEST  state  (d2)  will  not  exceed 
time-limit  T??  (see  Annex  4). 

When  the  datagram  logical  channel  is  in  the  DCE  RESET  INDICATION 
state,  the  DTE  will  confirm  reset  by  transmitting  to  the  DCE  a 
DTE  RESET  CONFIRMATION  packet.  This  places  the  datagram  logical 
channel  in  the  FLOW  CONTROL  READY  state  (dl).  The  action  taken 
by  the  DCE  when  the  DTE  does  not  confirm  the  reset  within  time¬ 
out  Tl?  is  given  in  Annex  4. 

5 . 3  Effects  o f  Reset  and  Restart  Procedures  on  the  Transfer  of 
Jacket s 


For  datagram  logical  channels,  the  reset  and  restart  procedures 
cause  datagrams  and  datagram  service  signals  to  be  purged  from 
the  DCE  queue.  A  datagram  service  signal  with  the  cause  "Remote 
procedure  error"  will  be  issued  to  the  remote  end  for  each 
dataqram  requesting  the  non-delivery  indication  facility. 

5.4  Effects  of  Physical  and  Link  Level  Failures 

When  a  failure  on  physical  and/or  link  level  is  detected,  the  DCE 
will  purge  datagrams  and  datagram  service  signals  from  the  DCE 
queue  associated  with  each  datagram  logical  channel  and,  for  each 
datagram  requesting  the  non-delivery  indication  facility, 
transmit  to  the  remote  end  a  datagram  service  signal  with  the 
cause  "Out  of  order". 

During  the  failure,  the  DCE  will  discard  any  incoming  datagrams 
and  datagram  service  signals.  A  datagram  service  signal  with  the 
cause  "Out  of  order"  will  be  sent  to  the  remote  end  for  each 
datagram  requesting  the  non-delivery  indication  facility. 

When  the  failure  is  recovered  on  the  physical  and  link  levels, 
the  restart  procedure  will  be  actioned  (see  section  3.5).  Upon 
completion  of  this  procedure,  incoming  datagrams  and  datagram 
service  signals  will  be  handled  in  the  normal  manner. 


-  63 


6 .  PACKET  FORMATS 
6  .  1  General 

The  possible  extension  of  packet  formats  by  the  addition  of  new 
fields  is  for  further  study. 

Note :  Any  such  field: 

(a}  would  only  be  provided  as  an  addition  following  all  pre¬ 
viously  defined  fields,  and  not  as  an  insertion  between 
any  of  the  previously  defined  fields, 

(b)  would  be  transmitted  to  a  DTE  only  when  either  the  DCE 
has  been  informed  that  the  DTE  is  able  to  interpret  this 
field  and  act  upon  it,  or  when  the  DTE  can  ignore  the 
field  without  adversely  affecting  the  operation  of  the 
DCE. 

(c)  would  not  contain  any  information  pertaining  to  a  user 
facility  to  which  the  DTE  has  not  subscribed. 

Bits  of  an  octet  are  numbered  8  to  1  where  bit  1  is  the  low  order 
bit  and  is  transmitted  first.  Octets  of  a  packet  are  consecu¬ 
tively  numbered  starting  from  1  and  are  transmitted  in  this 
order . 

6,1.1  General  Format  Identifier 

The  General  Format  Identifier  field  is  a  four  bit  binary  coded 
field  which  is  provided  to  indicate  the  general  format  of  the 
rest  of  the  header.  The  General  Format  Identifier  field  is 
located  in  hit  positions  8,  7,  f  and  5  of  octet  1,  and  bit  5  is 
the  low  order  bit  (see  Table  6.1/X.25). 
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TABLE  R.1/X.2S 
GENERAL  FORMAT  IDENTIFIER 


'  Octet  1 

GENERAL  FORMAT  IDENTIFIER  bits 

P  7  6  5 

Gall  set-up 
packets 

Sequence  numbering  scheme  0  X  P  1 

modulo  R 

Sequence  numbering  scheme 
modulo  128 

n  X  1  0  ‘ 

Clearing,  datagram,  flow 
control,  interrupt, 
reset  ,  restart  and 
diagnostic  packets 

Sequence  numbering  scheme 
modulo  R 

0  0  0  1 

Sequence  numbering  scheme 
modulo  128 

n  o  l  o  : 

1 

Data  packets 

Sequence  numbering  scheme 
modulo  8 

X  X  0  1  | 

Sequence  numbering  scheme 
modulo  1 28 

x  x  1  n 

Datagram  service  signal 
packets 

Sequence  numbering  scheme 
modulo  8 

10  0  1 

Sequence  numbering  scheme 
modulo  128 

10  10 

General  Format  Identifier  extension 

*  *  l  l 

•Undefined 


Note:  A  bit  which  is  indicated  as  "X"  may  be  set  to  either  "0"  or 
"1"  as  discussed  in  subsequent  sections. 


Bit  B  of  the  General  Format  Identifier  is  used  for  the  Qualifier 
bit  in  data  packets.  It  is  set  to  1  in  datagram  service  signal 
packets  and  is  set  to  0  in  all  other  packets. 

Bit  7  of  the  General  Format  Identifier  is  used  for  the  delivery 
confirmation  procedure  in  data  and  call  set-up  packets  and  is  set 
to  0  in  all  other  packets. 

Bits  fi  and  5  are  encoded  for  four  possible  indications.  Two  of 
the  codes  are  used  to  distinguish  packets  using  modulo  8  sequence 
numbering  from  packets  using  modulo  128  sequence  numbering.  The 
third  code  is  used  to  indicate  an  extension  to  an  expanded  format 
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for  a  family  of  Genera]  Format  Identifier  codes  which  arc  a  sub¬ 
ject  of  further  study.  The  fourth  code  is  unassigned. 

Note  1 :  In  the  absence  of  the  Extended  Packet  Sequence  Numbering 
facility  (see  section  7.1.1),  the  sequence  numbering 
scheme  is  performed  modulo  8. 

Note  2:  It  is  envisaged  that  other  General  Format  Identifier 
codes  could  identify  alternative  packet  formats. 

6.1.2  Logical  Channel  Group  Nunber 

The  Logical  Channel  Group  Number  appears  in  every  packet  except 
restart  packets  and  diagnostic  packets  in  bit  positions  4,  3,  2 
and  1  of  octet  1.  For  each  logical  channel,  this  number  has 
local  significance  at  the  DTE/DCE  interface. 

This  field  is  binary  coded  and  bit  1  is  the  low  order  bit  of  the 
Logical  Channel  Group  Number.  In  restart  and  diagnostic  packets, 
this  field  is  coded  all  zeros. 

6.1.3  Logical  Channel  Number 

The  Logical  Channel  Number  appears  in  every  packet  except  restart 
packets  and  diagnostic  packets  in  all  bit  positions  of  octet  2. 
For  f'ach  logical  channel,  this  number  has  local  significance  at 
the  DTE/DCE  interface. 

This  field  is  binary  coded  and  bit  1  is  the  low  order  bit  of  the 
Logical  Channel  Number.  In  restart  and  diagnostic  packets,  this 
field  is  coded  all  zeros. 

6.1.4  Packet  Type  Identifier 

Each  packet  shall  be  identified  in  octet  3  of  the  packet  accord¬ 
ing  to  Table  6.2/X.25. 
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TABLE  A. 2/X . 25 
PACKET  TYPE  IDENTIFIER 


PACKET 

TYPE  ! 

OCTF 

rr« 

1 

c 

- — . - 

I 

B 

IT 

S 

FRO*  DCE  TO  DTE 

FRO*  DTE  TO  DCE  i 

P 

7 

f, 

5 

A 

3 

0 

4 

1 

CALL  SET-UP 

AND  CLEARING 

: 

INCOMING  CALL 

CALL  REQUEST 

0 

n 

0 

0 

1 

0 

1 

1  ' 

CALL  CONNECTED 

CALL  ACCEPTED 

0 

0 

0 

0 

1 

1 

1 

1  , 

CLEAR  INDICATION 

CLEAR  REQUEST 

0 

0 

0 

1 

0 

0 

1 

i  ! 

DCE  CLEAR  CONFIRMATION 

DTE  CLEAR  CONFIRMATION 

0 

n 

0 

1 

0 

1 

1 

i  i 

DATA  AND 

INTERRUPT 

DCE  DATA 

DTE  DATA 

X 

X 

X 

X 

X 

X 

X 

0 

DCE  INTERRUPT 

DTE  INTERRUPT 

0 

0 

1 

0 

0 

0 

1 

1 

DCE  INTERRUPT 

DTE  INTERRUPT 

CONFIRMATION 

CONFIRMATION 

0 

0 

1 

0 

0 

1 

1 

1 

DATAGRAM* 

DCE  DATAGRAM 

DTE  DATAGRAM 

X 

X 

X 

X 

X 

X 

X 

0 

DATAGRAM  SERVICE  SIGNAL 

X 

X 

X 

X 

X 

X 

X 

0 

FLOW  CONTROL 

AND  RESET 

DCE  RR  (MODULO  8) 

DTE  RR  (MODULE  8) 

X 

X 

X 

0 

0 

0 

0 

1 

DCE  RR  (MODULO  128)* 

DTE  RR  (MODULO  128)* 

0 

0 

0 

0 

0 

0 

0 

1 

DCE  RNR  (MODULO  8) 

DTE  RNR  (MODULO  8) 

X 

X 

X 

n 

0 

1 

0 

1 

DCE  RNR  (MODULO  128)* 

DTE  RNR  (MODULO  128)* 

0 

0 

0 

0 

0 

1 

0 

1 

DTE  REJ  (MODULO  8)* 

X 

X 

X 

0 

1 

0 

0 

1 

DTE  REJ  (MODULO  128)* 

0 

n 

0 

0 

1 

0 

0 

1 

RESET  INDICATION 

RESET  REQUEST 

0 

0 

0 

l 

1 

0 

1 

1 

DCE  RESET  CONFIRMATION 

DTE  RESET  CONFIRMATION 

0 

0 

0 

l 

1 

1 

1 

1 

RESTART 

RESTART  INDICATION 

RESTART  REQUEST 

1 

1 

1 

1 

1 

0 

1 

1 

DCE  RESTART  CONFIRMATION 

DTE  RESTART  CONFIRMATION 

1 

l 

1 

l 

1 

1 

1 

1 

DIAGNOSTIC 

DIAGNOSTIC* 

1 

l 

1 

l 

0 

0 

0 

1 

*  Not  necessarily  available  on  every  network. 


Note :  A  bit  which  is  indicated  as  "X"  may  be  set  to  either  *0"  or 
•1"  as  discussed  in  subsequent  sections. 
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6 .  2  Call  Set-Up  anr1  Clearing  Packets 

6.2.1  Call  Request  and  Incoming  Call  Packets 

Figure  fi.l/X.25  illustrates  the  format  of  CALL  REQUEST  and  INCOM¬ 
ING  CALL  packets. 

General  Format  Identifier 


Bit  7  of  octet  1  should  be  set  to  0  unless  the  mechanism  defined 
in  section  4.3.3  is  used. 

Address  Lengths  Field 

Octet  4  consists  of  field  length  indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2  and  1  indicate  the  length  of 
the  called  DTE  address  in  semi-octets.  Bits  8,  7,  fi  and  5  indi¬ 
cate  the  length  of  the  calling  DTE  address  in  semi-octets.  Each 
address  lenqth  indicator  is  binary  coded  and  bit  1  or  5  is  the 
low  order  bit  of  the  indicator. 

Address  Field 


Octet  5  and  the  following  octets  consist  of  the  called  DTE 
address  when  present,  then  the  calling  DTE  address  when  present. 

Each  digit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  octet 
5  and  consecutive  octets  with  two  digits  per  octet.  In  each 
octet,  the  higher  order  digit  is  coded  in  bits  8,  7,  6  and  5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 

Note :  This  field  may  be  used  for  optional  addressing  facilities 
such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  well  as  the  coding  of  thos.e  facili¬ 
ties  is  for  further  study. 

Facility  Length  Field 

Bits  fi,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  indicator. 

Bits  fl  and  7  of  this  octet  are  unassigned  and  set  to  0. 
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Called  DTE  address 

length 

1 ength 

1 

1 

1 

I>TF  Address  (See  Note  2)  ■ 

1 

1 

1 
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Facility  length 
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1  1 

! _ 1 

r 

Call  User  Data  ^ 

i 

i 

i _ 

(See  Notes 

3  and  1* )  | 

1 

_ 

Note  1:  CoriQd  0X01  (modulo  8)  or  0X10  (modulo  128). 

Note  :  The  figure  is  drawn  assuming  a  single  address  is 
present  consisting  of  an  odd  number  of  digits. 

Note  3:  Bits  8  and  7  of  the  first  octet  of  the  Call 

User  Data  field  may  have  particular  significance 
(see  section  6.2.1). 

Note  it:  Maximum  length  of  the  Call  User  Data  field  is 
16  octets. 

6 . 1  / X . 2 ci  -  Call  request  and  incoming  call  packet  format 
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Facl I i ty  Field 

The  Facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
REQUEST  and  INCOMING  CALL  packets. 

The  coding  of  the  Facility  field  is  defined  in  section  7. 

The  Facility  field  contains  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However,  this  maximum  does  not 
exceed  63  octets. 

Call  User  Data  Field 


Following  the  Facility  field,  the  Call  User  Data  field  may  be 
present  and  has  a  maximum  length  of  16  octets. 

Note :  At  present,  some  networks  require  the  Call  User  Data 

field  to  contain  an  integral  number  of  octets  (see  sec¬ 
tion  3 ,  No 2 )  . 

If  the  Call  User  Data  field  is  present,  the  use  and  format  of 
this  field  is  determined  by  bits  8  and  7  of  the  first  octet  of 
this  field  (see  Note). 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  00,  a  portion  of  the  Call  User  Data  field  is  used  for  proto¬ 
col  identification  in  accordance  with  other  CCITT  Recommendations 
such  as  Recommendation  X.29. 

If  bits  R  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  01,  a  portion  of  the  Call  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  specifications  of 
Administrations . 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  10,  a  portion  of  the  Call  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  spec i f i r at i ons  of 
international  user  bodies. 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  11,  no  constraints  are  placed  on  the  use  by  the  DTE  of  the 
remainder  of  the  Call  User  Data  field. 

Users  are  cautioned  that  if  bits  R  and  7  of  the  first  octet  of 
the  Call  User  Data  field  have  any  value  other  than  11,  a  protocol 
may  be  identified  that  is  implemented  within  public  data  net¬ 
works. 

Note:  When  a  virtual  call  is  being  established  between  two  pack'. t 
mode  DTEs,  the  network  does  not  act  on  any  part  of  the  vail 
User  Data  field,  unless  required  to  do  otherwise  by  an 
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appropriate  request  for  an  optional  user  facility  on  a  per 
call  basis.  Such  a  facility  is  for  further  study. 

6.2.2  Call  A ccepted  and  Call  Connected  Packets 

Figure  6.2/X. 25  illustrates  the  format  of  CALL  ACCEPTED  and  CALL 
CONNECTED  packets. 

Gener al  Format  Identifier 

Bit  7  of  octet  1  should  be  set  to  0  unless  the  mechanism  defined 
in  section  4.7.7  is  used. 

Address  Lenaths  Field 


Octet  4  consists  of  field  length  indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2  and  1  indicate  the  length  of 
the  called  DTE  address  in  semi-octets.  Bits  8,  7,  6  and  5  indi¬ 
cate  the  length  of  the  calling  DTE  address  in  semi-octets.  Each 
address  length  indicator  is  binary  coded  and  bit  1  or  5  is  the 
low  order  bit  of  the  indicator. 

The  use  of  the  Address  Lengths  field  in  CALL  ACCEPTED  packets  is 
only  mandatory  when  the  Address  field  or  the  Facility  Length 
field  is  present . 

Address  Field 

Octet  5  and  the  following  octets  consist  of  the  called  DTE 
address  when  present,  then  the  calling  DTE  address  when  present. 

Each  diqit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in 
octet  5  and  consecutive  octets  with  two  digits  per  octet.  In 
each  octet,  the  higher  order  digit  is  coded  in  bits  8,  7,  6  and 
5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  Inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 

Note :  This  field  may  be  used  for  optional  addressing  facilities 

such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  well  as  the  coding  of  those  facili¬ 
ties  is  for  further  study. 
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Facility  Lengt h  Field 

Bits  6,  6,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 

indicate  the  lenoth  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  indicator. 

Bits  P  and  7  of  this  octet,  are  unassigned  and  set  to  P. 

The  use  of  the  Facility  Length  field  in  CALL  ACCEPTED  packets  is 
only  mandatory  when  the  Facility  field  is  present. 

Facility  Field 

The  Facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
ACCEPTED  and  CALL  CONNECTED  packets. 

The  coding  of  the  Facility  field  is  defined  in  section  7. 

The  Facility  field  contains  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However ,  this  maximum  does  not 
exceed  63  octets. 

6.2.3  Clear  Request  and  Clear  Indication  Packets 

Figure  6.3/X.26  illustrates  the  format  of  CLEAR  REQUEST  and  CLEAR 
INDICATION  packets. 

Clearing  Cause  Field 

Octet  4  is  the  Clearing  Cause  field  and  contains  the  reason  for 
the  clearing  of  the  call. 

Tne  bits  of  the  Clearing  Cause  field  in  CLEAR  REQUEST  packets 
should  be  set  to  0  by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 

The  coding  of  the  Clearing  Cause  field  in  CLEAR  INDICATION  pack¬ 
ets  is  given  in  Table  6.3/X.25. 
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Logical  Cn ar.r.ei 
Grouj  Number 


General  Ktrirut 
I  der.*  i  i'i  er 
See  Note 

Logical 
Channel  Number 


Packet  T)’ffc  Identifier 

0  001  0011 


Clearing  Cause 


Diagnostic  Code 


•  -’it*  e  •  Codec  0001  (modulo  8)  or  0010  (modulo  128) 

This  field  is  not  mandatory  in  CLEAR  REQUEST  packets. 

=  6.3/X.25  -  Clear  request  and  clear  indication  packet  format 


-  74 


TARLE  6.3/X.7S 

CODING  OF  CLEARING  CAUSE  FIELD  IN  CLEAR  INDICATION  PACKET 


P 

7 

r 

s 

4 

3 

n 

DTF  oriqinated 

P 

n 

0 

0 

0 

0 

0 

0  ’ 

N amber  busy 

0 

0 

0 

p 

p 

p 

p 

1 

Out  of  order 

0 

0 

0 

0 

1 

0 

n 

1 

Remote  procedure  error 

Reverse  charging  acceptance 

0 

0 

0 

1 

0 

0 

0 

1  ; 

not  s  ub  sc  r i bed  * 

n 

o 

p 

1 

1 

0 

0 

1  : 

Incompatible  destination 

Fast  select  acceptance 

0 

n 

1 

p 

0 

p 

0 

!  i 

not  subset i bed* 

0 

0 

1 

0 

1 

0 

0 

1 

Invalid  facility  request 

0 

n 

0 

0 

0 

0 

1 

1  ' 

Access  barred 

0 

n 

0 

0 

1 

0 

1 

1 

Local  procedure  error 

0 

p 

0 

1 

0 

0 

1 

1 

Network  congestion 

0 

0 

0 

0 

0 

1 

0 

1  ! 

Not  obtainable 

0 

0 

0 

p 

1 

1 

0 

1 

RPOA  out  of  order* 

0 

p 

0 

1 

0 

1 

0 

L 

*  May  be  received  only  if  the  corresponding  optional  user  facil¬ 
ity  is  used  . 


Diagnostic  Code 

Octet  5  is  the  Diagnostic  Cede  and  contains  additional  informa¬ 
tion  on  the  reason  for  the  clearing  of  the  call. 

In  a  CLEAR  REOUEST  packet,  the  Diagnostic  Code  is  not  mandatory. 

In  a  CLEAR  INDICATION  packet,  if  the  Clearing  Cause  field  indi¬ 
cates  "DTE  originated,"  the  Diagnostic  Code  is  passed  unchanged 
from  the  clearing  DTE.  If  the  clearing  DTE  has  not  provided  a 
Diagnostic  Code  in  its  CLEAR  REQUEST  packet,  then  the  bits  of  the 
Diagnostic  Code  in  the  resulting  CLEAR  INDICATION  packet  will  all 
be  lero. 

When  a  CLEAR  INDICATION  packet  results  from  a  RESTART  REQUEST 
packet,  the  value  of  the  Diagnostic  Code  will  be  that  specified 
in  the  RESTART  REQUEST  packet,  or  all  zeros  in  the  case  where  no 
Diagnostic  Code  has  been  specified  in  RESTART  REQUEST. 

When  the  clearing  Cause  field  does  not  indicate  "DTE  oriqinat- 

ed , "  the  Diagnostic  Code  in  a  CLEAR  INDICATION  packet  is  network 
generated.  Annex  5  lists  the  codings  for  network  generated 
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diagnostics.  The  bits  of  the  Diagnostic  Code  are  all  set  to  0 
when  no  specific  additional  information  for  the  clearing  is  sup¬ 
plied. 

Note :  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 

meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Ca use  field. 

6.2.4  DTE  and  DCE  Clear  Confirmation  Packets 

Figure  6.4/X.25  illustrates  the  format  of  the  DTE  and  DCE  CLEAR 
CONFIRMATION  packets. 

6 . 3  Data  and  Interrupt  Packets 

6.3,1  DTE  and  DCE  Data  Packets 

Figure  6.5/X.25  illustrates  the  format  of  the  DTE  and  DCE  DATA 
packets . 

Qualifier  Bit 


Bit  8  of  octet  1  is  the  Qualifier  bit. 

Delivery  Confirmation  Bit 

Bit  7  of  octet  1  is  the  Delivery  Confirmation  hit. 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3  or  bits  8  through  2  of  octet  4,  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P  (R )  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

More  Data  Bit 


Bit  5  in  octet  3,  or  bit  1  in  octet  4  when  extended,  is  used  for 
the  More  Data  mark:  0  for  no  more  data  and  1  for  more  data. 

Packet  Send  Sequence  Number 

Bits  4,  3  and  2  of  octet  3,  or  bits  8  through  2  of  octet  3  when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence  Number 
P (S ) .  P (S )  is  binary  coded  and  bit  2  is  the  low  order  bit. 


User  Hat  a  Field 


Bits  following  octet  3,  or  octet  4  when  extended,  contain  user 
data  . 

Note :  At  present,  some  networks  require  the  User  Data  field  to 

contain  an  integral  number  of  octets  (see  section  3,  Note 
2)  . 

6.3.2  DTE  and  DCF  Interrupt  Packets 

Fiqure  6.6/X.25  illustrates  the  format  of  the  DTE  and  DCE  INTER¬ 
RUPT  packets. 

Interrupt  User  Data  Field 

Octet  4  contains  user  data. 

6. 3. 3  DTE  and  DCE  Interrupt  Confirmation  Packets 

Figure  6.7/X.25  illustrates  the  format  of  the  DTE  and  DCE  INTER¬ 
RUPT  CONFIRMATION  packets. 

6 . 4  Datagram  and  Datagram  Service  Signal  Packets 
6.4.1  DTE  and  DCE  Datagram  Packets 

Figure  6.8/X.25  illustrates  the  format  of  DTE  and  DCE  DATAGRAM 
packets  . 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P (R )  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

Packet  Send  Sequence  Number 

Bits  4,  3  and  2  of  octet  3,  or  bits  B  through  2  of  octet  3  when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence 
Number  P(S).  P (S )  is  binary  coded  and  bit  2  is  the  low  order 
bit. 

Address  Lengths  Field 

The  octet  following  the  sequence  numbers  consists  of  field  length 
indicators  for  the  destination  and  source  DTE  addresses.  Bits  4, 
3,  2  and  1  indicate  the  length  of  the  destination  DTE  address  in 
semi-octets.  Bits  8,  7,  6  and  S  indicate  the  length  of  the 
source  DTE  address  in  semi-octets.  Each  address  length  indicator 
is  binary  coded  and  bit  1  or  5  is  the  low  order  bit  of  the  indi¬ 
cator. 
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Firure  ^.P/X.?5  -  DTE  and  DCE  dntarram  packet  format 


Address  Field 


The  octets  following  the  Address  Length  field  consist  of  the  des¬ 
tination  DTF  address  when  present,  then  the  source  DTE  address 

when  present. 

Each  digit  of  an  address  is  coded  in  a  semi-octet,  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  con¬ 
secutive  octets  with  two  digits  per  octet.  In  each  octet,  the 
higher  order  digit  is  coded  in  bits  P ,  7,  6  and  5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 

Note :  This  field  may  be  used  for  optional  addressing  facilities 

such  as  abbreviated  addressing.  The  optional  addressinq 
facilities  employed  as  well  as  the  coding  of  those  facili¬ 
ties  is  for  further  study. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  indicator. 

Bits  8  and  7  of  this  octet  are  unassigned  and  set  to  0. 

Facl llty  Field 

The  Facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  datagram 
packet . 

The  coding  of  this  Facility  field  is  defined  in  section  7. 

The  Facility  field  contains  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However  this  maximum  does  not 
exceed  63  octets. 

User  Data  Field 


Following  the  Facility  field,  the  User  Data  field  may  be  present 
and  has  a  maximum  length  of  128  octets.  The  first  two  octets  of 
the  User  Data  field  are  called  the  datagram  identification. 

Note:  At  present,  some  networks  require  the  User  Data  field  to 

contain  an  integral  number  of  octets  (see  section  3,  Note 
2)  . 


^•4.2  Datagram  Service  Signal  Facets 

Figure  6.9/X.2S  illustrates  the  format  of  DATAGRAM  SERVICE  SIGNAL 
packets . 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  fi  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

Packet  Send  Sequence  Number 

Bit  4,  3  and  2  of  octet  3,  or  bits  8  through  2  of  octet  3  when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence 
Number  P(S).  P(S)  is  binary  coded  and  bit  2  is  the  low  order 
bit. 

Address  Lengths  Field 

The  octet  following  the  sequence  numbers  consists  of  field  length 
indicators  for  the  destination  and  source  DTE  addresses.  Bits  4, 
3,  2  and  1  Indicate  the  length  of  the  destination  DTE  address  in 
semi-octets.  Bits  8,  7,  6  and  5  indicate  the  length  of  the 
source  DTE  address  in  semi-octets.  Each  address  length  indicator 
is  binary  coded  and  bit  1  or  5  is  the  low  order  bit  of  the  indi¬ 
cator  . 

The  source  DTE  address  length  indicator  is  coded  all  zeros  for 
datagram  service  signal  -  general  packets. 

Address  Field 


The  octets  following  the  Address  Length  field  consist  of  the  des¬ 
tination  DTE  address  when  present,  then  the  source  DTE  address 
when  present  (see  section  5.  1.4.1). 

Each  digit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  con¬ 
secutive  octets  with  two  digits  per  octet.  In  each  octet,  the 
higher  order  digit  is  coded  in  bits  8,  7,  6  and  5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 
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Datagram  Identification  Field 

The  Datagram  Identification  field  of  datagram  service  signal  - 
specific  packets  contains  the  first  two  octets  of  the  User  Data 
field  from  the  original  datagram  to  which  the  datagram  service 
signal  packet  applies.  If  the  User  Data  field  of  the  original 
datagram  is  less  than  two  octets,  the  Datagram  Identification 
field  in  the  datagram  service  signal  packet  will  be  padded  out  to 
two  octets  by  inserting  the  appropriate  number  of  0  bits. 

The  Datagram  Identification  field  of  datagram  service  signal  - 
general  packets  is  coded  with  all  zeros. 

Cause  Field 


The  octet  immediately  following  the  Datagram  Identification  field 
is  the  Cause  field  and  contains  the  reason  for  the  datagram  ser¬ 
vice  signal. 

The  coding  of  the  Cause  field  is  given  in  Table  6.4/X.25. 


TABLE  S.4/X.25 


CODING  OF  CAUSE  FIELD  IN  DATAGRAM  SERVICE  SIGNAL  PACKET 


P 

7 

6 

5 

4 

3 

2 

1  1 

Datagram  Service  Signal  -  Specific 

: 

Datagram  Rejected 

! 

1 

1 

Local  procedure  error 

0 

0 

0 

1 

0 

n 

1 

1  : 

Invalid  facility  request 

n 

0 

0 

0 

0 

0 

1 

1  i 

Access  barred 

0 

0 

0 

0 

1 

0 

1 

1 

Not  obtainable 

0 

0 

0 

0 

1 

1 

0 

Incompatible  destination 

0 

n 

1 

0 

0 

0 

0 

1 1 

Reverse  charging  acceptance 

0 

0 

0 

1 

1 

0 

0 

1 

not  subscribed 

Datagram  Non-Delivery  Indication 

(Note  1) 

Network  congestion 

0 

0 

0 

0 

0 

1 

0 

1 

Out  of  order 

0 

0 

0 

0 

1 

0 

0 

1 

Number  busy  (destination  queue 

ful  1) 

0 

0 

0 

0 

0 

0 

0 

1 

Remote  procedure  error 

0 

0 

0 

1 

0 

0 

0 

1 

Datagram  Delivery  Confirmation  (Note  2) 

Delivery  confirmation 

0 

0 

1 

1 

0 

0 

0 

1 

Datagram  Service  Signal  -  General 

Local  DCE  queue  overflow  (Note 

3) 

0 

1 

1 

1 

1 

1 

1 

1 

Network  congestion 

0 

1 

0 

0 

0 

1 

1 

1 

Network  operational 

0 

1 

0 

0 

1 

1 

1 

1 

Note  1:  Issued  only  when  the  Non-delivery  Indication  facility 
(see  section  7.3.4)  has  been  requested. 

Note  2:  Issued  only  when  the  Delivery  Confirmation  facility  (see 
~  section  7.3.5)  has  been  requested. 

Note  3;  For  further  study. 


Diagnostic  Code 

The  octet  immediately  following  the  Cause  field  contains  addi¬ 
tional  information  on  the  reason  for  the  datagram  service  signal. 
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The  coding  of  the  Diagnostic  Code  field  is  given  in  Annex  5. 
Assigned  Diagnostic  Codes  applicable  to  datagram  service  signal 
packets  include  decimal  33,  38,  39,  40,  65,  66,  67  and  68.  The 
bits  of  the  Diagnostic  Code  in  a  datagram  service  signal  packet 
are  all  set  to  zero  when  no  specific  additional  information  for 
the  service  signal  is  supplied. 

Note:  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 

meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

Network  Information  Field 


Following  the  Diagnostic  Code  field,  the  Network  Information 
field  may  be  present  and  has  a  maximum  length  of  16  octets. 

If  the  Diagnostic  Code  field  designates  Facility  Code  Not  Allowed 
or  Facility  Parameter  Not  Allowed,  then  the  Network  Information 
field  will  contain  the  octets  associated  with  the  facility  code 
and  its  associated  parameter  field.  If  the  Diagnostic  Code  field 
designates  Invalid  Address,  then  the  Network  Information  Field 
will  contain  the  octets  associated  with  the  two  Address  Length 
fields  and  the  octets  associated  with  the  Address  field. 

The  information  content  of  this  field  for  other  Diagnostic  Codes 
is  for  further  study. 

6.5  Flow  Control  and  Reset  Packets 


6.5.1  DTE  and  DCE  Receive  Ready  (RR)  Packets 

Figure  6.10/X.25  illustrates  the  format  of  the  DTE  and  DCE  RR 
packets . 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P{R).  P  (R )  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

6.5.2  DTE  and  DCE  Receive  Not  Ready  (RNR )  Packets 


Figure  6.11/X.25  illustrates  the  format  of  the  DTE  and  DCE  RNR 
packets . 


Packet  Receive  Stauti'ct  Number 

Bits  B,  1  and  f>  of  octet  3,  or  hits  B  through  2  of  octet  4  when 
extended,  ar  <  used  for  indicating  the  racket  Receive  Sequence 
Number  P  (R )  .  P(R)  is  binary  coded  and  bit  fi ,  or  bit  2  when 
extended,  is  the  low  order  bit. 

6 . 5 . 3  Reset  Recruest  and  Reset  Indication  Packets 


Figure  R.12/X.2S  illustrates  the  format  of  the  RESET  REQUEST  and 
RESET  IN  P 1 CAT  I  ON  packets. 

Resetting  Cause  Field 

Octet  4  is  the  Resetting  Cause  field  and  contains  the  reason  for 
the  reset  . 

The  bits  of  the  Resetting  Cause  field  in  a  RESET  REO'JEST  packet 
should  be  set  to  n  by  the  PTE.  It  is  for  further  study  whether 
other  values  of  these  hits  are  ignored  or  processed  by  the  DCE. 

The  coding  of  the  Resetting  Cause  field  in  a  RESET  INDICATION 
packet  is  given  in  Table  s.S/X.25. 

TABLE  fi. 5/X .  2  5 


CODING  OF  RESETTING  CA'JPF  FIELD  IN  RESET  INDICATION  PACKET 


B 

7 

6 

5 

4 

3 

2 

1 

j  DTE  ori 

g inn' p  ' 

+  *■ 

0 

0 

0 

P 

P 

P 

P 

p 

Out  of 

o  r  d  e  r  * 

0 

n 

0 

0 

0 

0 

n 

1 

Remote 

pr  or ed  u 

r  e 

error** *** 

0 

0 

0 

0 

n 

P 

l 

1 

Local  procedur 

e 

error 

0 

0 

0 

0 

p 

1 

p 

1 

Network 

conq  pq 

t.  i 

')  n 

0 

0 

0 

0 

p 

1 

l 

1 

Remote 

DTE  ope 

r  a 

t  i  nna  1  * 

0 

n 

p 

p 

i 

0 

0 

1 

Ne  two  r  k 

opr  rat 

i  o  n  a  1  *  *  * 

0 

0 

0 

0 

l 

1 

1 

1 

I n  com  pa 

r  i  b  1  e  d 

e s t  :nat  i  r> r *  * 

n 

0 

0 

1 

p 

0 

0 

1 

*  Applicable  to  permanent  virtual  circuits  only. 

**  Applicable  to  virtual  calls  and  permanent  virtual  circuits  on 

***  Applicable  tr  permanent-  virtual  circuits  and  datagram  logical 
channels  only. 


AD-A092  394  NATIONAL  COMMUNICATIONS  SYSTEM  WASHINGTON  DC 
REVISED  CCITT  RECOMMENDATION  X.25  1980. (U> 
AU6  80  H  C  FOLTS 
UNCLASSIFIED  NCS-TIB-80-5 


b9 


Bits 


87651*321 


Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 


*  This  field  is  not  mandatory  in  RESET  REQUEST  packets. 
Figure  6.12/X.25  -  Reset  request  and  reset  indication  packet  format 


BitB 


6  7  6  5  »*  3  2  1 


Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

Figure  6.13/X.25  -  DTE  and  DCE  reset  confirmation  packet  format 
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Diaanostic  Code 


Octet  5  is  the  Diagnostic  Code  and  contains  additional  informa¬ 
tion  on  the  reason  for  the  reset. 

In  a  RESET  REQUEST  packet  the  Diagnostic  code  is  not  mandatory. 

In  a  RESET  INDICATION  packet,  if  the  Resetting  Cause  field  indi¬ 
cates  "DTE  originated,"  the  Diagnostic  Code  has  been  passed 
unchanged  from  the  resetting  DTE.  If  the  DTE  requesting  a  reset 
has  not  provided  a  Diagnostic  Code  in  its  RESET  REQUEST  packet, 
then  the  bits  of  the  Diagnostic  Code  in  the  resulting  RESET  INDI¬ 
CATION  packet  will  all  be  zeros. 

If  a  RESET  INDICATION  packet  results  from  a  RESTART  REQUEST 
packet,  the  value  of  the  Diagnostic  Code  will  be  that  specified 
in  the  RESTART  REQUEST,  or  all  zeros  in  the  case  where  no  Diag¬ 
nostic  Code  has  been  specified  in  RESTART  REQUEST. 

If  the  Resetting  Cause  field  does  not  indicate  "DTE  originated", 
the  Diagnostic  Code  in  a  RESET  INDICATION  packet  is  network  gen¬ 
erated.  Annex  5  lists  the  codings  for  network  generated  diagnos¬ 
tics.  The  bits  of  the  Diagnostic  Code  are  all  set  to  0  when  no 
specific  additional  information  for  the  reset  is  supplied. 

Note:  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 

meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

6.5.4  DTE  and  DCE  Reset  Confirmation  Packets 

Figure  6.13/X.25  illustrates  the  format  of  the  DTE  and  DCE  RESET 
CONFIRMATION  packets. 

6.6  Restart  Packets 


6.6.1  Restart  Request  and  Restart  Indication  Packets 

Figure  6.14/X.25  illustrates  the  format  of  the  RESTART  REQUEST 
and  RESTART  INDICATION  packets. 

Restarting  Cause  Field 

Octet  4  is  the  Restarting  Cause  field  and  contains  the  reason  for 
the  restart. 

The  bits  of  the  Restarting  Cause  field  in  RESTART  REQUEST  packets 
should  be  set  to  0  by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 
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Bits 

t  7  6  r,  I4  3  2  1 


1 

General  Format 

Identifier 

See  Note 

o 

° 

o 

o 

2 

0  0  0  0 

0  0  0  0 

3 

Packet  Type  Identifier 

11111011 

1* 

Restarting  Cause 

5 

Diagnostic  Code* 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

*  This  field  is  not  mandatory  in  RESTART  REQUEST  packets 
Figure  6.1k/X.25  -  Restart  request  and  restart  indication  packet  format 


Bits 


8 

7 

6  5 

l 

3 

2 

1 

Octet  1 

General  Format 

Identifier 

See  Note 

0 

0 

0 

c 

2 

0 

0 

0  0 

0 

0 

0 

0 

3 

1 

1 

Packet  Type 

1  1 

Identifier 

1 

1 

1 

1 

Note: 

Coded 

0001  (modulo 

8)  or  0010 

(modulo  128) 

Figure  6.1b/X.2 5  -  DTE  and  DCE  restart  confirmation  packet  format 
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The  coding  of  the  Restarting  Cause  field  in  the  RESTART  INDICA¬ 
TION  packets  is  given  in  Table  6.6/X.2 5. 

TABLE  6.6/X.25 

CODING  OF  RESTARTING  CAUSE  FIELD  IN  RESTART 
INDICATION  PACKETS 


8  7  6  5  4  3  2  1 

Local  procedure  error 

Network  congestion 

Network  operational 

0  0  0  0  0  0  0  1 

0  0  0  0  0  0  1  1 

0  0  0  0  0  1  1  1 

Diagnostic  Code 

Octet  5  is  the  Diagnostic  Code  and  contains  additional  informa¬ 
tion  on  the  reason  for  the  restart. 

In  a  RESTART  REQUEST  packet,  the  Diagnostic  Code  is  not  manda¬ 
tory.  The  Diagnostic  Code,  if  specified,  is  passed  to  the 
corresponding  DTEs  as  the  Diagnostic  Code  of  a  RESET  INDICATION 
packet  for  permanent  virtual  circuits  or  a  CLEAR  INDICATION 
packet  for  virtual  calls. 

The  coding  of  Diagnostic  Code  field  in  a  RESTART  INDICATION 
packet  is  given  in  Annex  5.  The  bits  of  the  Diagnostic  Code  are 
all  set  to  zero  when  no  specific  additional  information  for  the 
restart  is  supplied. 

Note:  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 
meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

fi.fi. 2  DTE  and  DCE  Restart  Confirmation  Packets 

Figure  6.15/X.25  illustrates  the  format  of  the  DTE  and  DCE  RES¬ 
TART  CONFIRMATION  packets. 

fi. 7  Diagnostic  Packet 

Figure  fi.lfi/X.25  illustrates  the  format  of  the  DIAGNOSTIC  packet. 


Octet 
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Bits 


8 _ 1  6  5  4  3  2  i 


General  Format 

Identifier 

0  0  0  0 

(See  Note  1) 

0  0  0  0 

0  0  0  0 

1111 

0  0  0  1 

Packet  Type 

Identifier 

Diagnostic  Code 

I 

5  Diagnostic  Explanation 

t  (See  Note  2) 

» 

I _ 


Note  1:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 


Note  2:  The  figure  is  drawn  assuming  the  Diagnostic 
"  Explanation  field  is  an  integral  number  of 

octets  in  length. 


Figure  6.16/X.25  -  Diagnostic  packet  format 


Octet  4  is  the  diagnostic  code  and  contains  information  on  the 
error  condition  which  resulted  in  the  transmission  of  the  DIAG¬ 
NOSTIC  packet.  The  coding  of  the  Diagnostic  Code  field  is  given 
in  Annex  5. 

Diagnostic  Explanation  Field 

When  the  DIAGNOSTIC  packet  is  issued  as  a  result  of  the  reception 
of  an  erroneous  packet  from  the  DTE  (see  Table  A3.1/X.25),  this 
field  contains  the  first  three  octets  of  header  information  from 
the  erroneous  DTE  packet.  If  the  packet  contains  less  than  3 
octets,  this  field  contains  whatever  bits  were  received. 

When  the  DIAGNOSTIC  packet  is  issued  as  a  result  of  a  DCE  timeout 
(see  Table  A4.1/X.25),  the  Diagnostic  Explanation  field  contains 
2  octets  coded  as  follows: 

-  Bits  8,  7,  fi  and  5  of  the  first  octet  contains  the  General 
Format  Identifier  for  the  interface. 

-  Bits  4  to  1  of  the  first  octet  and  bits  8  to  1  of  the  second 
octet  are  all  0  for  expiration  of  time-out  T10  and  give  the 
number  of  the  logical  channel  on  which  the  time-out  occurred 
for  expiration  of  time-out  T12  or  T13. 

6. 8  Packets  Required  for  Optional  User  Facilities 

A. 8.1  DTE  Reject  (REJ)  Packet  For  The  Packet  Retransmission 
Facility 

Figure  8.17/X.25  illustrates  the  format  of  the  DTE  REJ  packets, 
used  in  conjunction  with  the  Packet  Retransmission  facility 
described  in  section  7.1.4. 

Packet  Receive  Sequence  Number 


Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  ere  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P  (R )  is  binary  coded  and  bit  8,  or  bit  2  when 
extended,  is  the  low  order  bit. 

6.8.2  Call  Set-up  and  Clearing  Packets  For  The  Fast  Select 
Facility  and  Fast  Select  Acceptance  Facility 

6. 8. 2.1  Call  Request  and  Incoming  Call  Packets 

Figure  6.18/X.25  illustrates  the  format  of  CALL  REQUEST  and 
INCOMING  CALL  packets  used  in  conjunction  with  the  Fast  Select 
facility  and  Fast  Select  Acceptance  facility  described  in  sec¬ 
tions  7.2.4  and  7.2.5. 
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Octet 


Eits 

6  7  6  5  6  3  2  1 


1 

Generei  Fermat 

,  Ider.t  if ier 
(See  Note  1) 

Logical  Channel 

Grouj  Number 

n 

C. 

Logical 

Channel  Number 

3 

Packet  Type  Identifier 

0  0  0  0  1  0  1  1 

It 

Calling  DTE  address 

Called  DTE  address 

length 

length 

1 

I  Call  User  Data  I 

|  (See  Notes  3  and  k)  | 

i _ _i 


Note  1:  Coded  0X01  (modulo  8)  or  0X10  (modulo  128). 

Note  _2:  The  figure  i6  drawn  assuming  a  single  address  is 
present  consisting  of  an  odd  number  of  digits. 

Note  3:  Bits  8  and  7  of  the  first  octet  of  the  Call 

User  Data  field  may  have  particular  significance 
(see  section  6.2.1). 

Note  Maximum  length  of  the  Call  User  Data  field  is 
128  octets. 


Figure  6.18/X.25  -  Call  request  and  incoming  call  packet  format 
for  the  Fast  Select  facility 
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Description  of  section  6.2.1  is  applied  to  this  section  except 
the  length  of  the  Call  User  Data  field  has  a  maximum  length  of 
128  octets. 

Note:  At  present,  some  networks  require  the  Call  User  Data 

field  to  contain  an  integral  number  of  octets  (see  sec¬ 
tion  3,  Note  2)  . 

6. 8. 2. 2  Call  Accepted  and  Call  Connected  Packets 

Figure  6.19/X.25  illustrates  the  format  of  CALL  ACCEPTED  and  CALL 
CONNECTED  packets  used  in  conjunction  with  the  Fast  Select  facil¬ 
ity  and  Fast  Select  Acceptance  facility  described  in  sections 
7.2 .4  and  7.2.5. 

Description  of  section  6.2.2  is  applied  to  this  section  and,  in 
addition,  the  Called  User  Data  field  may  be  present  and  has  a 
maximum  length  of  128  octets.  The  Address  Lengths  field  and 
Facility  Length  field  are  mandatory. 

Note:  At  present,  some  networks  require  the  Called  User  Data 

field  to  contain  an  integral  number  of  octets  (see  sec¬ 
tion  3 ,  Note  2)  . 

If  the  Called  User  Data  field  is  present,  the  use  and  format  of 
this  field  is  determined  by  bits  8  and  7  of  the  first  octet  of 
this  field  (see  Note) . 

If  bits  8  and  7  of  the  first  octet  of  the  Called  User  Data  field 
are  00,  a  portion  of  the  Called  User  Data  field  is  used  for  pro¬ 
tocol  identification  in  accordance  with  other  CCITT  Recommenda¬ 
tions  . 

If  bits  8  and  7  of  the  first  octet  of  the  Called  User  Data  field 
are  01,  a  portion  of  the  Called  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  specifications  of 
Administrations . 

If  bits  8  and  7  of  the  first  octet  of  the  Called  Us.  r  Data  field 
are  10,  a  portion  of  the  Called  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  specifications  of 
International  user  bodies. 

If  bits  8  and  7  of  the  first  octet  of  the  Called  User  Data  field 
are  11,  no  constraints  are  placed  on  the  use  by  the  DTE  of  the 
remainder  of  the  Called  User  Data  field. 

Users  are  cautioned  that  if  bits  R  and  7  of  the  first  octet  of 
the  Called  User  Data  field  have  any  value  other  than  11,  a  proto¬ 
col  may  be  identified  that  is  implemented  within  public  data  net¬ 
works. 
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General  Format 
Identifier 
(See  Note  l) 

Logical  Channel 

Grouj  Number 

Logical 

Channel  Number 

0  0 

Packet  Type  Identifier 

0  0  1111 

Calling  DTE  address 
length 

Called  DTE  address 
length 

f 

I 

DTE  Address 

(See  Note  2)  1 

1 

1 

0  0  0  0 

0  0 

Facility  length 

1 

1 

I 

Facilities  . 

( 

1 

1 

1 

_ 1 

1  I 

|  Called  User  Data  | 

^  (See  Notes  3  and  I4 )  | 

1 _ _ _ 1 

Rote  1 :  Coded  0X01  (modulo  8)  or  0X10  (modulo  128). 

Note  2:  The  figure  is  drawn  assuming  a  single  address 

is  present  consisting  of  an  odd  number  of  digits. 

Note  3:  Bits  8  and  7  of  the  first  octet  of  the  Called 

User  Data  field  may  have  particular  significance 
(see  section  6. 8, 2. 2), 

Note  h :  Maximum  length  of  the  Called  User  Data  field  is 
128  octets. 


Figure  6.1?/X.25  -  Cail  accepted  and  cal 1  connected  packet  format 
for  the  Fast  Select  facility 


Note:  When  a  virtual  call  is  being  established  between  two 

packet  mode  DTEs  ,  the  network  does  not  act  on  any  part  of 
the  Called  User  Data  field,  unless  required  to  do  other¬ 
wise  by  an  appropriate  request  for  an  optional  user  facil¬ 
ity  on  a  per  call  basis.  Such  a  facility  is  for  further 
stud  y . 

6.8,2. 3  Clear  Request  and  Clear  Indication  Packets 

Figure  6.20/X.25  illustrates  the  format  of  CLEAR  REQUEST  and 
CLEAR  INDICATION  packets  used  in  conjunction  with  the  Fast  Select 
facility  and  Fast  Select  Acceptance  facility  described  in  sec¬ 
tions  7.2.4  and  7.2.5. 


Description  of  the  Clearing  Cause  field  and  the  Diagnostic  Code 
field  in  section  6.2.3  is  applied  to  this  section.  In  addition 
the  following  fields  may  follow  the  Diagnostic  Code  field  and  in 
such  cases  the  use  of  the  Diagnostic  Code  field  is  mandatory. 

Address  Lengths  Field 

Octet  S  consists  of  field  length  indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2  and  1  indicate  the  length  of 
the  called  DTE  addresses  in  semi-octets.  Bits  8,  7,  6  and  5 
indicate  the  length  of  the  calling  DTE  address  in  semi-octets. 
Each  address  length  indicator  is  binary  coded  and  bit  1  or  5  is 
the  low  order  bit  of  the  indicator. 

Note:  This  field  is  coded  with  all  Os.  Other  codings  are  for 

further  study. 

Address  Field 

Note :  Pending  the  further  study  indicated  above,  this  field  is 

not  present. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  facil¬ 

ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  indicator. 

Bits  8  and  7  of  this  octet  are  unassigned  and  set  to  0. 

Note:  This  field  is  coded  with  all  Os.  Other  codings  are  for 

further  study. 
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Note  1:  Coded  0001  (modulo  8)  or  0010  (modulo  123). 

Note  2:  The  figure  js  drawn  assuming  a  single  address 

is  present  consisting  of  an  odd  number  of  digit 
Net"  3:  Maximum  length  of  the  Clear  User  Data  field 
is  128  octets. 
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Facllity  Field 

Note :  Pending  the  further  study  indicated  above,  this  field  is 

not  present. 

Clear  User  Data  Field 

Following  the  Facility  field,  the  Clear  User  Data  field  may  be 
present  and  has  a  maximum  length  of  128  octets. 

Note :  At  present,  some  networks  require  the  Clear  User  Data 

field  to  contain  an  integral  number  of  octets  (see  sec¬ 
tion  3 ,  Note  2)  . 


7.  PROCEDURES  AND  FORMATS  FOR  OPTIONAL  USER  FACILITIES 

7.1  Procedures  for  Optional  User  Facilities  Associated  with  Vir¬ 
tual  Circuit  and  Datagram  Services 

7.1.1  Extended  Packet  Sequence  Numbering 

Extended  Packet  Sequence  Numbering  is  an  optional  user  facility 
agreed  for  a  period  of  time.  It  applies  in  common  to  all  logical 
channels  at  the  DTE/DCE  interface. 

This  user  facility,  if  subscribed  to,  provides  sequence  numbering 
of  packets  performed  modulo  128.  In  the  absence  of  this  facil¬ 
ity,  the  sequence  numbering  of  packets  is  performed  modulo  8. 

7.1.2  Nonstandard  Default  Window  Sizes 

Nonstandard  Default  Window  Sizes  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  facility,  if  subscribed  to, 
provides  for  the  selection  of  default  window  sizes  from  the  list 
of  window  sizes  supported  by  the  Administration.  Some  networks 
may  constrain  the  default  window  sizes  to  be  the  same  for  each 
direction  of  transmission  across  the  DTE/DCE  interface.  In  the 
absence  of  this  facility,  the  default  window  sizes  are  «. 

Values  other  than  the  default  window  sizes  may  be  negotiated  for 
a  virtual  call  by  means  of  the  Flow  Control  Parameter  Negotiation 
facility  (see  section  7.2.2).  Values  other  than  the  default  win¬ 
dow  sizes  may  be  agreed  for  a  period  of  time  for  each  permanent 
virtual  circuit  and  each  datagram  logical  channel. 

7.1.3  Default  Throughput  Classes  Assignment 

Default  Throughput  Classes  Assignment  is  an  optional  user  facil¬ 
ity  agreed  for  a  period  of  time.  This  facility,  if  subscribed 
to,  provides  for  the  selection  of  default  throughput  classes  from 
the  list  of  throughput  classes  supported  by  the  Administration. 
Some  networks  may  constrain  the  default  throughput  classes  to  be 


-  102  - 


the  sanr  for  each  direction  of  data  transmission.  In  the  absence 
of  this  facility,  the  default  throuqhput  classes  correspond  to 
the  user  class  of  service  of  the  DTE  (see  section  7. 4. 2. 6)  but  do 
not  exceed  the  maximum  throuqhput  class  supported  by  the  network. 

The  default  throuqhput  classes  are  the  maximum  throughput  classes 
which  nay  be  associated  with  any  virtual  call  at  the  DTE/DCE 
interface.  Values  other  than  the  default  throughput  classes  may 
be  negotiated  for  a  virtual  call  by  means  of  the  Throughput  Class 
Negotiation  facility  (see  section  7.2.3).  Values  other  than  the 
default  throuqhput.  classes  may  be  agreed  for  a  period  of  time  for 
each  permanent  virtual  circuit  and  each  datagram  logical  channel. 

7.1.4  Packet  Retransmission 

Packet  Retransmission  is  an  optional  user  facility  agreed  for  a 
period  of  time.  It  applies  in  common  to  all  logical  channels  at 
the  DTE/DCE  interface. 

Note :  In  this  section,  the  term  "flow  controlled  packet"  refers 

to  the  DCE  DATA  packet  for  virtual  call  and  permanent  vir¬ 
tual  circuit  logical  channels  and  refers  to  the  DCE 
DATAGRAM  and  DATAGRAM  SERVICE  SIGNAL  packets  for  datagram 
logical  channels. 

This  user  facility,  if  subscribed  to,  allows  a  DTE  to  request 
retransmission  of  one  or  several  consecutive  flow  controlled 
packets  from  the  DCE  by  transferring  across  the  DTE/DCE  interface 
a  DTE  REJECT  packet  specifying  a  logical  channel  number  and  a 
sequence  number  P  (R ) .  The  value  of  this  P(R)  should  be  within 
the  range  from  the  last  P(R)  received  by  the  DCE  up  to,  but  not 
including,  the  P(S)  of  the  next  flow  controlled  packet  to  be 
transmitted  by  the  DCE.  If  the  P(R)  is  outside  this  range,  the 
DCE  will  initiate  the  reset  procedure  with  the  cause  "Local  pro¬ 
cedure  error"  and  diagnostic  #2. 

When  receiving  a  DTE  REJECT  packet,  the  DCE  Initiates  on  the 
specified  logical  channel  retransmission  of  the  flow  controlled 
packets;  the  Packet  Send  Sequence  Numbers  of  which  are  starting 
from  P  (R )  where  P (R )  is  indicated  in  the  DTE  REJECT  packet. 

Until  the  DCE  transfers  across  the  DTE/DCE  interface  a  flow  con¬ 
trolled  packet  with  a  Packet  Send  Sequence  Number  equal  to  the 
P  (R )  indicated  in  the  DTE  REJECT  packet,  the  DCE  will  consider 
the  receipt  of  another  DTE  REJECT  packet  as  a  procedure  error  and 
reset  the  logical  channel. 

Additional  flow  controlled  packets  pending  initial  transmission 
may  follow  the  retransmitted  packet(s). 

A  DTE  receive  not  ready  situation  indicated  by  the  transmission 
of  RNR  packet  is  cleared  by  the  transmission  of  a  DTE  REJECT 
packet . 
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The  conditions  under  which  the  DCF  ignores  a  DTE  REJECT  packet, 
or  considers  it  as  a  procedure  error,  are  those  described  for 
flow  control  packets  (see  Annex  3). 

7.1.5  Incoming  Calls  Barred 

Incoming  Calls  Barred  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  applies  to  all  logical  channels 
used  at  the  DTE/DCE  interface  for  virtual  calls  and  datagrams. 

This  user  facility,  if  subscribed  to,  prevents  incoming  virtual 
calls  and  datagrams  from  being  presented  to  the  DTE.  The  DTE  may 
originate  outgoing  virtual  calls  and  datagrams. 

Note:  Logical  channels  used  for  virtual  calls  retain  their  full 

duplex  capability.  Logical  channels  used  for  datagrams 
and  datagram  service  signals  retain  their  capability  to 
convey  datagram  service  signals. 

7.1.6  Outgoing  Calls  Barred 

Outgoing  Calls  Barred  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  applies  to  all  logical  channels 
used  at  the  DTE/DCE  interface  for  virtual  calls  and  datagrams. 

This  user  facility,  if  subscribed  to,  prevents  the  DCE  from 
accepting  outgoing  virtual  calls  and  datagrams  from  the  DTE.  The 
DTE  may  receive  incoming  virtual  calls  and  datagrams. 

Note:  Logical  channels  used  for  virtual  calls  retain  their  full 

duplex  capability. 

7.1.7  One-way  Logical  Channel  Outgoing 

One-way  Logical  Channel  Outgoing  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  user  facility,  if  subscribed 
to,  restricts  the  logical  channel  use  to  originating  outgoing 
virtual  calls  or  datagrams  only. 

Note:  A  logical  channel  used  for  virtual  calls  retains  its  full 

duplex  capability.  A  logical  channel  used  for  datagrams 
and  datagram  service  signals  retains  its  capability  to 
convey  datagram  service  signals. 

The  rules  according  to  which  Logical  Channel  Group  Numbers  and 
Logical  Channel  Numbers  can  be  assigned  to  one-way  outgoing  logi¬ 
cal  channels  for  virtual  calls  are  given  in  Annex  1. 

If  all  the  logical  channels  for  virtual  calls  and 
datagrams  are  one-way  outgoing  at  a  DTE/DCE  interface, 
the  effect  is  equivalent  to  the  Incoming  Calls  Barred 
facility  (see  section  7.1.5). 


Note : 
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7 . 1 . P  One-way  Logical  Channel  Incoming 

One-way  Logical  Channel  Incoming  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  user  facility,  if  subscribed 
to,  restricts  the  logical  channel  use  to  receiving  Incoming  vir¬ 
tual  calls  or  datagrams  only. 

Note:  A  logical  channel  used  for  virtual  calls  retains  its  full 

duplex  capability. 

The  rules  according  to  which  Logical  Channel  Group  Numbers  and 
Logical  Channel  Numbers  can  be  assigned  to  one-way  incoming  logi¬ 
cal  channels  for  virtual  calls  are  given  in  Annex  1. 

Note :  If  all  the  logical  channels  for  virtual  calls  and 

datagrams  are  one-way  incoming  at  a  DTE/DCE  interface, 
the  effect  is  equivalent  to  the  Outgoing  Calls  Barred 
facility  (see  section  7.1.6). 

7.1.9  Closed  User  Group 

Closed  User  Group  is  an  optional  user  facility  agreed  for  a 
period  of  time  for  virtual  calls  or  datagrams.  This  facility,  if 
subscribed  to,  enables  the  DTE  to  belong  to  one  or  more  closed 
user  groups.  A  closed  user  group  permits  the  DTEs  belonging  to 
the  group  to  communicate  with  each  other,  but  precludes  communi¬ 
cation  with  all  other  DTEs. 

The  calling/source  DTE  should  specify  the  closed  user  group 
selected  for  a  virtual  call  or  datagram  using  the  optional  user 
facility  parameters  (see  section  7. 4. 2.1)  in  the  CALL  REQUEST  or 
DTE  DATAGRAM  packet. 

The  closed  user  group  selected  for  a  virtual  call  or  datagram 
will  be  indicated  to  a  called/destination  DTE  using  the  optional 
user  facility  parameters  (see  section  7. 4. 2.1)  in  the  INCOMING 
CALL  or  DCE  DATAGRAM  packet. 

When  a  DTE  only  belongs  to  one  closed  user  group  or  when  the  vir¬ 
tual  call  or  datagram  is  associated  with  the  DTE's  preferential 
closed  user  group,  this  indication  may  not  be  present  in  the  CALL 
REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  or  DCE  DATAGRAM  packet. 

7.1.10  Closed  User  Group  with  Outgoing  Access 

Closed  User  Group  with  Outgoing  Access  is  an  optional  user  facil¬ 
ity  agreed  for  a  period  of  time  for  virtual  calls  or  datagrams. 
This  user  facility,  if  subscribed  to,  enables  the  DTE  to  belong 
to  one  or  more  closed  user  groups  (as  in  section  7.1.9)  and  to 
originate  virtual  calls  or  datagrams  to  DTEs  in  the  open  part  of 
the  network  and  to  DTEs  having  the  incoming  access  capability. 


] 
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The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  section  7.1.9.  However,  the  optional  user  facility 
parameters  may  not  be  present  when  originating  virtual  calls  or 
datagrams  to  DTEs  in  the  open  part  of  the  network  or  to  DTEs  hav¬ 
ing  the  incoming  access  capability. 

7.1.11  Closed  User  Group  with  Incoming  Access 

Closed  User  Group  with  Incoming  Access  is  an  optional  user  facil¬ 
ity  agreed  for  a  period  of  time  for  virtual  calls  or  datagrams. 
This  user  facility,  if  subscribed  to,  enables  the  DTE  to  belong 
to  one  or  more  closed  user  groups  (as  in  section  7.1.9)  and  to 
receive  incoming  calls  or  datagrams  from  DTEs  in  the  open  part  of 
the  network  and  from  DTEs  having  the  outgoing  access  capability. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  section  7.1.9.  However,  the  optional  user  facility 
parameters  may  not  be  present  when  receiving  incoming  calls  or 
datagrams  from  DTEs  in  the  open  part  of  the  network  or  from  DTEs 
having  the  outgoing  access  capability. 

7.1.12  Incoming  Calls  Barred  within  a  Closed  User  Group 

Incoming  Calls  Barred  within  a  Closed  User  Group  is  an  optional 
user  facility  agreed  for  a  period  of  time.  This  user  facility, 
if  subscribed  to  for  a  given  closed  user  group,  permits  the  DTE 
to  originate  virtual  calls  or  datagrams  to  DTEs  in  this  closed 
user  group,  but  precludes  the  reception  of  incoming  calls  or 
datagrams  from  other  DTEs  in  this  closed  user  group. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  sections  7.1.9,  7.1.10  and  7.1.11. 

7.1.13  Outgoing  Calls  Barred  within  a  Closed  User  Group 

Outgoing  Calls  Barred  within  a  Closed  User  Group  is  an  optional 
user  facility  agreed  for  a  period  of  time.  This  user  facility, 
if  subscribed  to  for  a  given  closed  user  group,  permits  the  DTE 
to  receive  virtual  calls  or  datagrams  from  other  DTEs  in  this 
closed  user  group,  but  prevents  the  DTE  from  originating  virtual 
calls  or  datagrams  to  other  DTEs  in  this  closed  user  group. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  sections  7.1.9,  7.1.10  and  7.1.11. 

7.1.14  Bilateral  Closed  User  Group 

Bilateral  Closed  User  Group  is  an  optional  user  facility  agreed 
for  a  period  of  time  for  virtual  calls  or  datagrams.  This  facil¬ 
ity,  if  subscribed  to,  enables  the  DTE  to  belong  to  one  or  more 
bilateral  closed  user  groups.  A  bilateral  closed  user  group  per¬ 
mits  a  pair  of  DTEs  who  bilaterally  agree  to  communicate  with 
each  other  to  do  so,  but  precludes  communication  with  all  other 
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DTEs  . 

The  calling/source  DTE  should  specify  the  bilateral  closed  user 
group  selected  for  a  virtual  call  or  datagram  using  the  optional 
user  facility  parameters  (see  section  7.4.2.21  in  the  CALL 
REDDEST  or  DTE  DATAGRAM  packet.  The  c al 1 ed/dest i net i on  DTE 
address  length  shall  be  coded  all  zeros. 

The  bilateral  closed  user  group  for  a  virtual  call  or  datagram 
will  be  indicated  to  a  called/destination  DTE  using  the  optional 
user  facility  parameters  in  the  INCOMING  CALL  or  DCE  DATAGRAM 
packet  . 

7.1.15  Bilateral  Closed  User  Group  with  Outgoing  Access 

Bilateral  Closed  User  Group  with  Outgoing  Access  is  an  optional 
user  facility  agreed  for  a  period  of  time  for  virtual  calls  or 
datagrams.  This  facility,  if  subscribed  to,  enables  the  DTE  to 
belong  to  one  or  more  bilateral  closed  user  groups  (as  in  section 
7.1.14)  and  to  originate  virtual  calls  or  datagrams  to  DTEs  in 
the  open  part  of  the  network. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  section  7.1.14. 

7.1.16  Reverse  Charging 

Reverse  Charging  is  an  optional  user  facility  which  can  be 
requested  by  a  DTE  for  a  given  virtual  call  or  for  a  datagram 
(see  section  7. 4. 2. 3). 

7.1.17  Reverse  Charging  Acceptance 

Reverse  Charging  Acceptance  is  an  optional  user  facility  agreed 
for  a  period  of  time. 

This  user  facility,  if  subscribed  to,  authorizes  the  DCE  to 
transmit  to  the  DTE  incoming  calls  or  datagrams  which  request  the 
Reverse  Charging  facility.  In  the  absence  of  this  facility,  the 
DCE  will  not  transmit  to  the  DTE  incoming  calls  or  datagrams 
which  request  the  Reverse  Charging  facility. 

7.1.10  RPOA  Selection 

RPOA  Selection  is  an  optional  user  facility  which  may  be 
requested  by  a  DTE  for  a  given  virtual  call  or  for  a  datagram. 

This  user  facility,  when  requested,  provides  for  the  user  specif¬ 
ication  by  the  calling/source  DTE  of  a  particular  RPOA  transit 
network  through  which  the  call  or  datagram  is  to  be  routed  inter¬ 
nationally,  when  more  than  one  RPOA  transit  network  exists  at  an 
International  gateway  (see  section  7. 4. 2. 4). 
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7.2  Procedures  for  Optional  User  Facilities  Only  Available  with 
Virtual  Circuit  Services  ” 

7.2.1  Nonstandard  Default  Packet  Sizes 

Nonstandard  Default  Packet  Sizes  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  facility,  if  subscribed  to, 
provides  for  the  selection  of  default  packet  sizes  from  the  list 
of  packet  sizes  supported  by  the  Administration.  Some  networks 
may  constrain  the  packet  sizes  to  be  the  same  for  each  direction 
of  data  transmission  across  the  DTE/DCE  interface.  In  the 
absence  of  this  facility,  the  default  packet  sizes  are  128 
octets . 

Note:  In  this  section,  the  term  "packet  sizes”  refers  to  the 

maximum  User  Data  field  lengths  of  DCE  DATA  and  DTE  DATA 
packets. 

Values  other  than  the  default  packet  sizes  may  be  negotiated  for 
a  virtual  call  by  means  of  the  Flow  Control  Parameter  Negotiation 
facility  (see  section  7.2.2).  Values  other  than  the  default 
packet  sizes  may  be  agreed  for  a  period  of  time  for  each  per¬ 
manent  virtual  circuit. 

7.2.2  Flow  Control  Parameter  Negotiation 

Flow  Control  Parameter  Negotiation  is  an  optional  user  facility 
agreed  for  a  period  of  time  which  can  be  used  by  a  DTE  for  vir¬ 
tual  calls.  This  facility,  if  subscribed  to,  permits  negotiation 
on  a  per  call  basis  of  the  flow  control  parameters.  The  flow 
control  parameters  considered  are  the  packet  and  window  sizes  at 
the  DTE/DCE  interface  for  each  direction  of  data  transmission. 

Note:  In  this  section,  the  term  "packet  sizes"  refers  to  the 

maximum  User  Data  field  lengths  of  DCE  DATA  and  DTE  DATA 
packets. 

In  the  absence  of  the  Flow  Control  Parameter  Negotiation  facil¬ 
ity,  the  flow  control  parameters  to  be  used  at  a  particular 
DTE/DCE  interface  are  the  default  packet  sizes  (see  section 
7.2.1)  and  the  default  window  sizes  (see  section  7.1.2). 

When  the  calling  DTE  has  subscribed  to  the  Flow  Control  Parameter 
Negotiation  facility,  it  may  separately  request  packet  sizes  and 
window  sizes  for  each  direction  of  data  transmission  (see  section 
7. A, 2. 5).  If  a  particular  window  size  is  not  explicitly 
requested  in  a  CALL  REQUEST  packet,  the  DCE  will  assume  that  the 
default  window  size  was  requested.  If  a  particular  packet  size 
is  not  explicitly  requested,  the  DCE  will  assume  that  the  default 
packet  size  was  requested. 


When  a  called  DTE  has  subscribed  to  the  Flow  Control  Parameter 
Negotiation  facility,  each  INCOMING  CALL  packet  will  indicate  the 
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packet  and  window  sizes  from  which  DTE  negotiation  can  start.  No 
relationship  needs  to  exist  between  the  packet  and  window  sizes 
requested  in  the  CALL  REQUEST  packet  and  those  indicated  In  the 
INCOMING  CALL  packet.  The  called  DTE  may  request  window  and 
packet  sizes  with  facilities  in  the  CALL  ACCEPTED  packet.  The 
only  valid  facility  requests  in  the  CALL  ACCEPTED  packet,  as  a 
function  of  the  facility  indications  in  the  INCOMING  CALL  packet, 
are  given  in  Table  7.1/X.25.  If  the  facility  request  is  not  made 
in  the  CALL  ACCEPTED  packet,  the  DTE  is  assumed  to  have  accepted 
the  indicated  values  (regardless  of  the  default  values). 

TABLE  7.1/X.25 

VALID  FACILITY  REQUESTS  IN  CALL  ACCEPTED  PACKET  IN  RESPONSE 
TO  FACILITY  INDICATIONS  IN  INCOMING  CALL  PACKET 


Facility  Indication 

W(indicated)  _>  2 
W(indicated)  ■  1 
P(indicated)  >.  128 
P  (ind  icated)  <  128 


Valid  Facility  Request 

W(indicated)  W(requested)  2 

W(requested)  *  1  or  2 
P(indicated)  P(requested)  128 

128  2.  P(requested)  >  P(indicated) 


When  the  calling  DTE  has  subscribed  to  the  Flow  Control  Parameter 
Negotiation  facility,  every  CALL  CONNECTED  packet  will  Indicate 
the  packet  and  window  sizes  to  be  used  at  the  DTE/DCE  interface 
for  the  call.  The  only  valid  facility  indications  in  the  CALL 
CONNECTED  packet,  as  a  function  of  the  facility  request*  in  the 
CALL  REQUEST  packet,  are  given  in  Table  7.2/X.25. 
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VAMP  FACILITY  INDICATION'!  IN  CALI-  CONNECTED  PACKET  IN 
RESPONSE  TO  I  ABILITY  REQUESTS  IN  CALL.  REQUEST  PACKET 


Fac i 1 i r  y  Request 

Valid  Facility  Indication 

W ( r  eque  st  ed )  >2 

W(requested)  W(indicated)  >  2 

W(requested)  =  1 

W ( ind  icated)  =  1  or  2 

P(requested)  128 

P(requested)  P(indicated)  >  128 

P(requested)  <  128 

128  >  P(indicated)  >  P(requested)  j 

The  network  may  have  constraints  requiring  the  flow  control 
parameters  used  for  -  call  to  be  modified  before  indicating  them 
to  the  DTE  in  the  I...  OMTNG  CALL  packet  or  CALL  CONNECTED  packet; 
e.g.,  the  ranges  of  parameter  values  available  on  various  net¬ 
works  may  differ. 

Window  and  packet  sizes  need  not  be  the  same  at  each  end  of  a 
virtual  call. 

The  role  of  the  DCE  in  negotiating  the  flow  control  parameters 
may  be  network  dependent. 

7.2.3  Throughput  Class  N eqot i at i on 

Throughput  Class  Negotiation  is  an  optional  user  facility  agreed 
for  a  period  of  time  which  can  be  used  by  a  DTE  for  virtual 
calls.  This  facility,  if  subscribed  to,  permits  negotiation  on  a 
per  call  basis  of  the  throughput  classes.  The  throughput  classes 
are  considered  independently  for  each  direction  of  data  transmis¬ 
sion. 

Default  values  are  agreed  between  the  DTE  and  the  Administration 
(see  section  7.1.3).  The  default  values  correspond  to  the  max¬ 
imum  throughput  classes  which  may  be  associated  with  any  virtual 
call  at  the  DTE/DCE  interface. 

When  the  calling  DTE  has  subscribed  to  the  Throughput  Class  Nego¬ 
tiation  facility,  it  may  separately  request  the  throughput 
classes  of  the  virtual  call  in  the  CALL  REQUEST  packet  (see  sec¬ 
tion  7. 4. 2. 6).  If  particular  throughput  classes  are  not 
requested,  the  DCE  will  assume  th*.  default  values. 

When  a  called  DTE  has  subscribed  to  the  Throughput  Class  Negotia¬ 
tion  facility,  each  INCOMING  CALL  packet  will  indicate  the 
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throuqhput  classes  fron  which  DTE  neqotiation  may  start.  These 
throughput  classes  an  lower  or  equal  to  the  ones  selected  at  the 
crlling  DTE/r'T  interface,  either  explicitly,  or  by  default  if 
the  calling  DTF.  has  not  subscribed  to  the  Throughput  Class  Nego¬ 
tiation  facility  or  has  not  explicitly  requested  throughput  class 
values  in  the  CALL  REQUEST  packet.  These  throughput  classes 
indicated  to  the  called  DTE  will  also  not  be  higher  than  the 
default  throughput  classes,  respectively  for  each  direction  of 
transmission,  at  the  callinq  and  the  called  DTE/DCE  interfaces. 
They  may  be  further  constrained  by  internal  limitations  of  the 
network. 

The  called  DTE  nay  request  with  a  facility  in  the  CALL  ACCEPTED 
packet  the  throughput  classes  that  should  finally  apply  to  the 
virtual  call.  The  only  valid  throughput  classes  in  the  CALL 
ACCEPTED  packet  are  lower  than  or  equal  to  the  ones  (respec¬ 
tively)  indicated  in  the  INCOMING  CALL  packet.  If  the  called  DTE 
does  not  make  any  throughput  class  facility  request  in  the  CALL 
ACCEPTED  packet,  the  throughput  classes  finally  applying  to  the 
virtual  call  will  be  the  ones  indicated  in  the  INCOMING  CALL 
packet . 

If  the  called  DTE  has  not  subscribed  to  the  Throughput  Class 
Negotiation  facility,  the  throughput  classes  finally  applying  to 
the  virtual  call  are  less  than  or  equal  to  the  ones  selected  at 
the  calling  DTE/DCE  interface,  and  less  than  or  equal  to  the 
default  values  defined  at  the  called  DTE/DCE  interface. 

When  the  calling  DTE  has  subscribed  to  the  Throughput  Class  Nego¬ 
tiation  facility,  every  CALL  CONNECTED  packet  will  indicate  the 
throughput  classes  finally  applying  to  the  virtual  call. 

When  neither  the  callinq  DTE  nor  the  called  DTE  has  subscribed  to 
the  Throughput  Class  Negotiation  facility,  the  throughput  classes 
applying  to  the  virtual  call  will  not  be  higher  than  the  ones 
agreed  as  defaults  at  the  calling  and  called  DTE/DCE  interfaces. 
They  may  be  further  constrained  to  lower  values  by  the  network, 
e.g.,  for  international  service. 

Note  1:  Since  both  Throughput  Class  Negotiation  and  Flow  Control 
Parameter  Negotiation  (see  section  7.2.2)  facilities  can 
be  applied  to  a  single  call,  the  achievable  throughput 
will  depend  on  how  users  manipulate  the  D  bit. 

Note  2:  Users  are  cautioned  that  the  choice  of  too  small  a  win¬ 
dow  and  packet  size  of  a  DTE/DCE  interface  (made  by  use 
of  the  Flow  Control  Parameter  Negotiation  facility)  may 
adversely  affect  the  attainable  throughput  class  of  a 
virtual  call.  This  is  likewise  true  of  flow  control 
mechanisms  adopted  by  the  DTE  to  control  data  transmis¬ 
sion  from  the  DCE. 
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7.2.4  Fast  Select 


Fast  Select  is  an  optional  user  facility  which  may  be  requested 
by  a  DTE  for  a  given  virtual  call. 

DTEs  can  request  the  Fast  Select  facility  on  a  per  call  basis  by 
means  of  an  appropriate  facility  request  (see  section  7.4. 2.7)  in 
a  CALL  REQUEST  packet  using  any  logical  channel  which  has  been 
assigned  to  virtual  calls. 

The  Fast  Select  facility,  if  requested  in  the  CALL  REQUEST  packet 
and  if  it  indicates  no  restriction  on  response,  allows  this 
packet  to  contain  a  Call  User  Data  field  of  up  to  128  octets  and 
authorizes  the  DCE  to  transmit  to  the  DTE,  during  the  DTE  waiting 
state,  a  CALL  CONNECTED  packet  with  a  Called  User  Data  field  of 
up  to  128  octets  or  a  CLEAR  INDICATION  packet  with  a  Clear  User 
Data  field  of  up  to  128  octets. 


The  Fast  Select  facility,  if  requested  in  the  CALL  REQUEST  packet 
and  if  it  indicates  restriction  on  response,  allows  this  packet 
to  contain  a  Call  User  Data  field  of  up  to  120  octets  and  author¬ 
izes  the  DCE  to  transmit  to  the  DTE,  during  the  DTE  waiting 
state,  a  CLEAR  INDICATION  packet  with  a  Clear  User  Data  field  of 
up  to  128  octets;  the  DCE  would  not  be  authorized  to  transmit  a 
CALL  CONNECTED  packet. 

Where  a  DTE  requests  the  Fast  Select  facility  in  a  CALL  REQUEST 
packet,  the  INCOMING  CALL  packet  should  be  only  delivered  to  the 
called  DTE  if  that  DTE  has  subscribed  to  the  Fast  Select  Accep¬ 
tance  facility  (see  section  7.2.5). 


If  the  called  DTE  has  subscribed  to  the  Fast  Select  Acceptance 
facility,  it  will  be  advised  that  the  Fast  Select  facility,  and 
an  indication  of  whether  or  not  there  is  a  restriction  on  the 
response,  has  been  requested  through  the  inclusion  of  the 
appropriate  facility  in  the  INC ON  TNG  CALL  packet. 

If  the  called  DTE  has  not  subscribed  to  the  Fast  Select  Accep¬ 
tance  facility,  an  INCOMING  CALL  packet  with  the  Fast  Select 
facility  requested  will  not  be  transmitted  and  a  CLEAR  INDICATION 
packet  with  the  cause  "Fast  select  acceptance  not  subscribed" 
will  be  returned  to  the  calling  DTE. 

The  presence  of  the  Fast  Select  facility  indicating  no  restric¬ 
tion  on  response  in  an  INCOMING  CALL  packet  permits  the  DTE  to 
issue  as  a  direct  response  to  this  packet  a  CALL  ACCEPTED  packet 
with  a  Called  User  Data  field  of  up  to  128  octets  or  a  CLEAR 
REQUEST  packet  with  a  Clear  User  Data  field  of  up  to  128  octets. 

The  presence  of  the  Fast  Select  facility  indicating  restriction 
on  response  in  an  INCOMING  CALL  packet  permits  the  DTE  to  issue 
as  a  direct  response  to  this  packet  a  CLEAR  REQUEST  packet  with  a 
Clear  User  Data  field  of  up  to  128  octets;  the  DTE  would  not  be 
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authorized  to  send  a  CALL  ACCEPTED  packet. 

The  posribility  to  send  a  CLEAR  REQUEST  packet  with  a  Clear  User 
Data  field  up  to  1 2P  octets  at  any  time  instead  of  just  in  the 
DCF  WAITING  state  ( p ? )  is  for  further  study. 

Note:  The  Call  User  Data  field,  the  Called  User  Data  field  and 

the  Clear  User  Data  field  will  not  be  fragmented  for 
delivery  across  the  DTE/DCE  interface. 

The  significance  of  the  CALL  CONNECTED  packet  and  the  CLEAR  INDI¬ 
CATION  packet  with  the  cause  "DTE  originated"  as  a  direct 
response  to  the  CALL  REQUEST  packet  with  the  Fast  Select  facility 
is  that  the  CALL  REQUEST  packet  with  the  data  field  has  been 
received  by  the  called  DTE. 

All  other  procedures  of  a  call  in  which  the  Fast  Select  facility 
has  been  requested  are  the  same  as  those  of  a  virtual  call. 

7.2.5  Fast  Select  Acceptance 

Fast  Select  Acceptance  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  user  facility,  if  subscribed  to,  authorizes 
the  DCE  to  transmit  to  the  DTE  incoming  calls  which  request  the 
Fast  Select  facility.  In  the  absence  of  this  facility,  the  DCE 
will  not  transmit  to  the  DTE  incoming  calls  which  request  the 
Fast  Select  facility. 

7. 2. fi  D  Bit  Modification 

D  Bit  Modification  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  applies  to  all  virtual  calls  and 
permanent  virtual  circuits  at  the  DTE/DCE  interface.  This  facil¬ 
ity  is  only  intended  for  use  by  those  pre  D  bit  DTEs  which  were 
designed  for  operation  on  Public  Data  Networks  that  support  end- 
to-end  P(R)  significance.  It  allows  these  DTEs  to  continue  to 
operate  with  end-to-end  P  (R )  significance  within  a  national  net¬ 
work  after  the  network  supports  the  delivery  confirmation  (D  bit) 
procedure . 

This  facility,  when  subscribed  to,  will  for  communications  within 
the  national  network: 

(a)  change  the  value  of  the  D  bit  from  0  to  1  in  all  CALL 
REQUEST,  CALL  ACCEPTED  and  DTE  DATA  packet?  received 
from  the  DTE,  and 

(b)  set  the  D  bit  to  0  in  all  INCOMING  CALL,  CALL  CONNECTED 
and  DCE  DATA  packets  transmitted  to  the  DTE. 

For  international  operation,  conversion  (b)  above  applies  and 
conversion  (a)  above  does  not  apply.  Other  conversion  rules  for 
int ernat i onal  operation  are  for  bilateral  agreement  between 
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Adm in i st  r a t  i ons . 

7. 3  Procedures  for  Optional  User  Facilities  Only  Available  with 
Datagram  Service 

7.3.1  Abbreviated  Address 

Abbreviated  Address  an  optional  user  facility  agreed  for  a  period 
of  time.  This  facility  permits  encoding  of  addresses  into 
shorter  representations  as  agreed  between  the  Administration  and 
DTE.  Initially  this  facility  is  restricted  to  a  lsl  mapping  of 
single  addresses,  but  1:N  mapping  for  multiple  addresses  is  for 
further  study. 

7.3.2  Datagram  Queue  Length  Selection 

Datagram  Queue  Length  Selection  is  an  optional  user  facility 
agreed  for  a  period  of  time  for  each  datagram  logical  channel. 
This  facility  enables  selection  of  the  number  of  datagram  and 
datagram  service  signal  packets  that  will  be  stored  in  a  queue  by 
the  destination  DCE  when  the  rate  of  arrival  of  packets  at  the 
destination  DCE  from  other  sources  exceeds  the  rate  of  delivery 
of  packets  to  the  destination  DTE. 

7.3.3  Datagram  Service  Signal  Logical  Channel 

Datagram  Service  Signal  Logical  Channel  is  an  optional  user 
facility  agreed  for  a  period  of  time.  This  facility  provides  a 
separate  logical  channel  for  the  DTE  to  receive  only  datagram 
service  signals.  This  enables  the  DTE  to  separately  flow  control 
datagram  service  signal  packets  from  the  datagram  packets. 

7.3.4  Datagram  Non-delivery  Indication 

Datagram  Non-delivery  Indication  is  an  optional  user  facility 
which  may  be  agreed  for  a  period  of  time  or  selected  on  a  per- 
datagram  basis  (see  section  7.4. 2.8). 

This  user  facility,  when  requested,  provides  for  a  non-delivery 
indication  service  signal  generated  by  the  network  when  a 
datagram  cannot  be  delivered  to  the  destination  DTE. 

7.3.5  Datagram  Delivery  Confirmation 

Datagram  Delivery  Confirmation  is  an  optional  user  facility  which 
may  be  agreed  for  a  period  of  time  or  selected  on  a  per-datagram 
basis  (see  section  7. 4. 2. 9). 

This  user  facility,  when  requested,  provides  for  a  delivery  con¬ 
firmation  service  signal  generated  by  the  network  after  the 
datagram  has  been  accepted  by  the  destination  DTE. 
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' ’ . t  Formats  for  Optional  User  Facilities 
7.4.1  General 

The  Facility  field  is  present  only  when  a  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
REQUEST,  INCOMING  CALL,  CALL  ACCEPTED,  CALL  CONNECTED,  CLEAR 
REQUEST,  CLEAR  INDICATION,  DTE  DATAGRAM  or  DCE  DATAGRAM  packet. 

The  Facility  field  contains  one  or  more  facility  elements.  The 
first  octet  of  each  facility  element  contains  a  facility  code  to 
indicate  the  facility  or  facilities  requested. 

Note ;  The  action  taken  by  the  DCE  when  a  facility  code  appears 
more  than  once  is  for  further  study. 

The  facility  codes  are  divided  into  four  classes,  by  making  use 
of  bits  8  and  7  of  the  facility  code  field,  in  order  to  specify 
facility  parameters  consisting  of  1,  2,  3,  or  a  variable  number 
of  octets.  The  general  class  coding  of  the  facility  code  field 
is  shown  below. 


bit 

8 

7 

8 

5 

4 

3 

2 

1 

CLASS 
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0 

0 
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X 

X 

X 

X 
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single 
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parameter 

field 

CLASS 
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1 

X 

X 

X 

X 

X 
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double 

octet 

parameter 

field 

CLASS 

C 

1 

0 

X 

X 

X 

X 

X 

X 

for 

tr iple 

octet 

parameter 

field 

CLASS 

D 

1 

1 

X 

X 

X 

X 

X 

X 

for 

variable  length  parameter  field 

For  class  D  the  octet  following  the  facility  code  indicates  the 
length,  in  octets,  of  the  facility  parameter  field.  The  facility 
parameter  field  length  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  this  indicator. 

The  formats  for  the  four  classes  are  shown  below. 
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CLASS  D 
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jU 
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The  facility  code  field  is  binary  coded  and,  without  extension, 
provides  for  a  maximum  of  64  facility  codes  for  classes  A,  B  and 
C  and  63  facility  codes  for  class  D  giving  a  total  of  255  facil¬ 
ity  codes . 

Facility  code  11111111  is  reserved  for  extension  of  the  facility 
code.  The  octet  following  this  octet  indicates  an  extended 
facility  code  having  the  format  A,  B,  C  or  D  as  defined  above. 
Repetition  of  facility  code  11111111  is  permitted  and  thus  addi¬ 
tional  extensions  result. 

The  coding  of  the  facility  parameter  field  is  dependent  on  the 
facility  being  requested. 

A  facility  code  may  be  assigned  to  identify  a  number  of  specific 
facilities,  each  having  a  bit  in  the  parameter  field  indicating 
facility  requested/facility  not  requested.  In  this  situation, 
the  parameter  field  is  binary  encoded  with  each  bit  position 
relating  to  a  specific  facility.  A  0  indicates  that  the  facility 
related  to  the  particular  bit  is  not  requested  and  a  1  indicates 
that  the  facility  related  to  the  particular  bit  is  requested. 
Parameter  bit  positions  not  assigned  to  a  specific  facility  are 
set  to  zero.  If  none  of  the  facilities  represented  by  the  facil¬ 
ity  code  are  requested  for  a  virtual  call  or  datagram,  the  facil¬ 
ity  code  and  its  associated  parameter  field  need  not  be  present. 


A  Facility  Marker,  consisting  of  a  single  octet  pair,  is  used  to 
separate  requests  for  X. 25  facilities,  as  defined  in  this  sec¬ 
tion,  from  requests  for  non-X.25  facilities  that  may  also  he 
offered  by  an  Administration.  The  first  octet  is  a  facility  code 
and  is  set  to  zero  and  the  second  octet  is  the  facility  parameter 
field. 

The  coding  of  the  parameter  field  will  be  either  all  zeros  or  all 
ones  depending  on  whether  the  facility  requests  following  the 
marker  refer  to  facilities  offered  by  the  calling/source  or 
called/destination  network,  respectively.  For  i n t r a-net wo r k  vir¬ 
tual  calls  or  datagrams,  the  parameter  field  should  be  all  zeros. 

Requests  for  non-X.25  facilities  offered  by  the  calling/source 
and  cal led/dest ination  networks  may  be  simultaneously  present 
within  the  facility  field  and  in  such  cases  two  Facility  Markers 
will  be  required  with  parameter  fields  coded  as  described  above. 

within  the  facility  field,  requests  for  X. 25  facilities  will  pre¬ 
cede  all  requests  for  non-X.25  facilities  and  Facility  Markers 
need  only  be  included  when  requests  for  non-X.25  facilities  are 
present . 

7 . A . 2  Coding  of  Facility  Field  for  Particular  Facilities 

7. 4. 2.1  Coding  of  Closed  User  Group  Facility 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  Closed  User  Group  are  the  same  in 
CALL  REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  and  DCE  DATAGRAM  pack¬ 
ets  . 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Closed  User  Groups  is: 
bit:  R  7  fi  5  4  1  2  1 

code:  00D0001  1 

Facility  Parameter  Field 

The  index  to  the  Closed  User  Group  selected  for  the  virtual  call 
or  datagram  is  in  the  form  of  two  decimal  digits.  Each  digit  is 
coded  in  a  semi-octet  in  binary  coded  decimal  with  bit  5  being 
the  low  order  bit  of  the  first  digit  and  bit  1  being  the  low 
order  bit  of  the  second  digit. 

Indexes  to  the  same  Closed  User  Group  at  different  DTE/DCE  inter¬ 
faces  may  be  different. 
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7.4.2.?  Coding  of  Bilaterial  Closed  User  Group  Facility 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  Bilateral  Closed  User  Group  are  the 
same  in  CALL  REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  and  DCE 
DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Bilateral  Closed  User 
Group  is: 

bit:  87654321 
code:  01000001 
Facility  Parameter  Field 

The  index  to  the  Bilateral  Closed  User  Group  selected  for  the 
virtual  call  or  datagram  is  in  the  form  of  4  decimal  digits. 

Each  digit  is  coded  in  a  semi-octet  in  binary  coded  decimal  with 
bit  5  of  the  first  octet  being  the  low  order  bit  of  the  first 
digit,  bit  1  of  the  first  octet  being  the  low  order  bit  of  the 
second  digit,  bit  5  of  the  second  octet  being  the  low  order  bit 
of  the  third  digit,  and  bit  1  of  the  second  octet  being  the  low 
order  bit  of  the  fourth  digit. 

Indexes  to  the  same  Bilateral  Closed  User  Group  at  different 
DTE/DCE  interfaces  may  be  different. 

7. 4. 2. 3  Coding  of  Reverse  Charging  Facility 

The  coding  of  the  facility  code  and  parameter  fields  for  Reverse 
Charging  is  the  same  in  CALL  REQUEST,  INCOMING  CALL,  DTE 
DATAGRAM,  and  DCE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Reverse  Charging  is: 


bit:  87654321 
code:  00000001 
Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 
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bit 


0  for  Reverse  Charging  not  requested 


Lit 


for  Reverse  Charging  requested 


Note : 


Bits  6,  5,  4,  3  and  2  may  be  used  for  other  facilities;  if 
not,  they  are  set  to  0.  Use  of  bits  8  and  7  are  described 
in  section  1 .4.2.1 . 


1.4. 2. 4  Coding  of  RPOA  Selection  Facility 

The  coding  of  the  facility  code  and  parameter  fields  for  RPOA 
Selection  is  the  same  in  CALL  REOUEST,  INCOMING  CALL,  DTE 
DATAGRAM  and  DCE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  RPOA  Selection  is: 
bit:  87654  321 

code:  01000100 


Facility  Parameter  Field 

The  parameter  field  contains  the  Data  Network  Identification  Code 
for  the  requested  RPOA  transit  network,  and  is  in  the  form  of  4 
decimal  digits. 

Each  digit  is  coded  in  a  semi-octet  in  binary  coded  decimal  with 
bit  5  of  the  first  octet  being  the  low  order  bit  of  the  first 
digit,  bit  1  of  the  first  octet  being  the  low  order  bit  of  the 
second  digit,  bit  5  of  the  second  octet  being  the  low  order  bit 
of  the  third  digit,  and  bit  1  of  the  second  octet  being  the  low 
order  bit  of  the  fourth  digit. 

7, 4. 2. 5  Coding  of  the  Flow  Control  Parameter  Negotiation  Facll- 

n* 

7, 4. 2. 5.1  Coding  for  Packet  Sizes 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  packet  sizes  are  the  same  in  CALL 
REOUEST,  INCOMING  CALL,  CALL  ACCEPTED,  and  CALL  CONNECTED  pack¬ 
ets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  packet  sizes  is: 
bit:  87654321 
code:  01000010 
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Facility  Parameter  Field 

The  packet  size  for  the  direction  of  transmission  from  the  called 
DTE  is  indicated  in  bits  4,  3,  2,  and  1  of  the  first  octet.  The 
packet  size  for  the  direction  of  transmission  from  the  calling 
DTE  is  indicated  in  bits  A,  3,  2,  and  1  of  the  second  octet. 

Bits  5,  6,  7  and  8  of  each  octet  must  be  zero. 

The  four  bits  indicating  each  packet  size  are  binary  coded  and 
express  the  logarithm  base  2  of  the  number  of  octets  of  the  max¬ 
imum  packet  size. 

Networks  may  offer  values  from  4  to  10,  corresponding  to  packet 
sizes  of  16,  32,  64,  128,  256,  512,  or  1024,  or  a  subset  of  these 
values.  All  Administrations  will  provide  a  packet  size  of  128. 

7. 4. 2. 5. 2  Coding  for  Window  Sizes 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  window  sizes  are  the  same  in  CALL 
REQUEST,  INCOMING  CALL,  CALL  ACCEPTED,  and  CALL  CONNECTED  pack¬ 
ets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  window  sizes  is: 
bit:  87654321 
code:  0100001  1 

Facility  Parameter  Field 

The  window  size  for  the  direction  of  transmission  from  the  called 
DTE  is  indicated  in  bits  7  to  1  of  the  first  octet.  The  window 
size  for  the  direction  of  transmission  from  the  calling  DTE  is 
indicated  in  bits  7  to  1  of  the  second  octet.  Bit  8  of  each 
octet  must  be  zero. 

The  bits  indicating  each  window  size  are  binary  coded  and  express 
the  size  of  the  window.  A  value  of  zero  is  not  allowed. 

Window  sizes  of  8  to  127  are  only  valid  for  calls  which  employ 
extended  numbering.  The  ranges  of  values  allowed  by  a  network 
for  calls  with  normal  numbering  and  extended  numbering  are  net¬ 
work  dependent.  All  Administrations  will  provide  a  window  size 
of  2. 
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7 . A . 2 . 6  Coding  of  Throughput  Class  Negotiation  Facility 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  Throughput  Class  Negotiation  are  the 
sane  in  CALL  REQUEST,  INCOMING  CALL,  CALL  ACCEPTED  and  CALL  CON¬ 
NECTED  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Throughput  Class  Nego¬ 
tiation  is ! 

bit :  87654321 

code:  00000010 

Facility  Parameter  Field 

The  throughput  class  for  transmission  from  the  calling  DTE  Is 
indicated  in  bits  4,  3,  2  and  1.  The  throughput  class  for 
transmission  from  the  called  DTE  Is  indicated  in  bits  8,  7,  6  and 
5. 

The  four  bits  indicating  each  throughput  class  are  binary  coded 
and  correspond  to  throughput  classes  as  indicated  below. 


bit:  4  3  2  1 

or  bit:  8765 


0  0  0  0 
0  0  0  1 
0  0  10 
0  0  11 


0  1  0 
0  1  1 
1  0  0 
1  0  1 


0  10  0 
0  10  1 
0  110 
0  111 
10  0  0 
10  0  1 
10  10 
10  11 
110  0 
110  1 
1110 


Throughput  class 
(bits  per  second) 

Reserved 
Reserved 
Reserved 
75 
150 
300 
600 
1,200 
2,400 
4,800 
9,600 
19, 200 
48,000 
Reserved 
Reserved 
Reserved 


7. 4. 2. 7  Coding  of  Past  Select  Facility 


The  coding  of  the  facility  code  and  parameter  fields  for  Past 
Select  is  the  same  in  CALL  REQUEST  and  INCOMING  CALL  packets. 
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Fjicj  ]  ij  y_  Code  F  i  e  1 

The  coding  of  the  facility  code  field  for  Fast  Select  is: 
bit:  8  7  6  6  4  3  2  1 

code:  0000(1001 

Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 

bit  8=0  and  bit  7  =  0  or  1  for  Fast  Select  not  requested 

bit  8  =  1  and  bit  7=0  for  Fast  Select  requested  with  no 

restriction  on  response 

bit  8=1  and  bit  7=1  for  Fast  Select  requested  with 

restriction  on  response 

Note :  Bits  6,  5,  4,  1  and  2  may  be  used  for  other  facilities;  if 
not,  they  ate  set  to  0.  Use  of  bit  1  is  described  in  sec¬ 
tion  7. 4. 2. 3. 

I 

7 . 4 . 2 . 8  Coding  of  Datagram  Non-delivery  Indication  Facility 

" 

The  coding  of  the  facility  code  and  parameter  fields  is  the  same 
in  the  DTE  DATAGRAM  and  DCE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Datagram  Non-delivery 

i  1  Indicationis: 

!  bit:  87654321 

t 

L 

[  .*’  code:  00000110 

1  , 

j  Facility  Parameter  Field 

*  The  coding  of  the  facility  parameter  field  is: 

*  » 

i  bit  2=0  for  Datagram  Non-delivery  Indication  not  requested 

I 

bit  2=1  for  Datagram  Non-delivery  Indication  requested 

Note:  Bits  8,  7,  6,  5,  4,  and  3  may  be  used  for  other  facili¬ 
ties;  if  not,  they  are  set  to  0.  Use  of  bit  1  is 
V  described  in  section  7.4. 2.9. 

t 

J 


;  1 

!  I 


•'*»  il  lillilltill  illlWniUma 
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1.4. 2. 9  Coding  of  Datagram  Delivery  Confirmation  Facility 

The  coding  of  the  facility  code  and  parameter  fields  is  the  sane 
in  the  DTE  DATAGRAM  and  DOE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Datagram  Delivery  Con¬ 
firmation  is: 

bit:  87654321 

code:  00000110 

Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 

bit  1*0  for  Datagram  Delivery  Confirmation  not  requested 

bit  1*1  for  Datagram  Delivery  Conf 1 rmation  requested 

Note:  Bits  8,  7,  6,  5,  4,  and  3  may  be  used  for  other  facili¬ 
ties;  if  not,  they  are  set  to  0.  Use  of  bit  2  is 
described  in  section  7. 4. 2.8. 
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ANNEX  1 

(to  Recommendation  X.25) 

RANGE  OF  LOGICAL  CHANNELS  USED  FOR  VIRTUAL  CALLS, 
PERMANENT  VIRTUAL  CIRCUITS  AND  DATAGRAMS 

In  the  case  of  a  single  logical  channel  DTE,  logical  channel  1 
will  be  used. 

For  each  multiple  logical  channel  DTE/DC E  interface,  a  range  of 
logical  channels  will  be  agreed  upon  with  the  Administration 
according  to  the  following  figure: 


LCN 


where : 


Logical  channels  1  to  LIC-1:  range  of  logical  channels  which  may 
be  assigned  to  permanent  virtual  circuits  and  datagrams. 


Logical  channels  LIC  to  HIC:  range  of  logical  channels  which  are 
assigned  to  one-way  incoming  logical  channels  for  virtual  calls 
(see  section  7.1.8). 


Logical  channels  LTC  to  HTC:  range  of  logical  channels  which  are 
assigned  to  two-way  logical  channels  for  virtual  calls. 


Logical  channels  LOC  to  HOC:  range  of  logical  channels  which  are 
assigned  to  one-way  outgoing  logical  channels  for  virtual  calls 
( see  section  7.1.7). 


Logical  channels  HIC+1  to  LTC-1,  HTC+1  to  LOC-1,  and  HOC+l  to 
4095  are  non-assigned  logical  channels. 
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Note  1 

Note  2 

No  te  3 

Note  4 

Note  5 

Note  6 


The  reference  to  the  numbers  of  logical  channels  is  made 
according  to  a  set  of  contiguous  numbers  from  0  (lowest) 
to  409B  (highest)  using  12  bits  made  up  of  the  4  bits  of 
the  Logical  Channel  Group  Number  (see  section  6.1.2)  and 
the  8  bits  of  the  Logical  Channel  Number  (see  section 
6.1.3).  The  numbering  is  binary  coded  using  bit  posi¬ 
tions  4  through  1  of  octet  1  followed  by  bit  positions  8 
through  1  of  octet  2  with  bit  1  of  octet  2  as  the  low 
order  bit. 

All  logical  channel  boundaries  are  agreed  with  the 
Administration  for  a  period  of  time. 

In  order  to  avoid  frequent  rearrangement  of  logical 
channels,  not  all  logical  channels  within  the  range  for 
permanent  virtual  circuits  or  datagrams  are  necessarily 
assigned  . 

In  the  absence  of  permanent  virtual  circuits  and 
datagram  channels,  logical  channel  1  is  available  for 
LIC.  In  the  absence  of  permanent  virtual  circuits, 
datagram  channels  and  one-way  incoming  logical  channels, 
logical  ch, nnel  1  is  available  for  LTC.  In  the  absence 
of  permanent  virtual  circuits,  datagram  channels,  one 
way  incoming  logical  channels  and  two-way  logical  chan¬ 
nels,  logical  channel  1  is  available  for  LOC. 

DCE  search  algorithm  for  a  logical  channel  for  a  new 
incoming  call  will  be  to  use  the  lowest  logical  channel 
in  the  READY  state  in  the  range  of  LIC  to  HIC  and  LTC  to 


In  order  to  minimize  the  risk  of  call  collision,  the  DTE 
search  algorithm  is  suggested  to  start  with  the  highest 
numbered  logical  channel  in  the  READY  state.  The  DTE 
could  start  with  the  two-way  logical  channel  or  one-way 
outgoing  logical  channel  ranges. 
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ANNEX  2 

(to  Recommendation  X.25) 

PACKET  LEVEL  DTE/DCE  INTERFACE  STATE  DIAGRAMS 


Note  1:  Each  state  is  represented  by  an  ellipse  wherein  the 
state  name  and  number  are  indicated. 

Note  2:  Each  state  transition  is  represented  by  an  arrow.  The 
responsibility  for  the  transition  (DTE  or  DCE )  and  the 
packet  that  has  been  transferred  are  indicated  beside 
that  arrow. 


Order  definition  of  the  steite  diagrams 


For  the  sake  of  clarity,  the  normal  procedure  at  the  interface  is 
described  in  a  number  of  small  state  diagrams.  In  order  to 
describe  the  normal  procedure  fully  it  J.  s  necessary  to  allocate  a 
priority  to  the  different  figures  and  to  relate  a  higher  order 
diagram  with  a  lower  one.  This  has  been  done  by  the  following 
means ; 

-  The  figures  are  arranged  in  order  of  priority  with  Figure 
A2.1/X.25  (Restart)  having  the  highest  priority  and  subse¬ 
quent  figures  having  lower  priority.  Priority  means  that 
when  a  packet  belonging  to  a  higher  order  diagram  is 
transferred,  that  diagram  is  applicable  and  the  lowei  order 
one  is  not. 

-  The  relation  with  a  state  in  a  lower  order  diagram  is  given 
by  including  that  state  inside  an  ellipse  in  the  higher 
order  diagram. 


NOTE  2 


Note  1 :  State  pi  for  virtual  calls  or  state  dl  for  permanent  virtual 
circuits  and  datagram. 

Note  2:  This  transition  may  take  place  after  timeout  T10. 

Figure  A2.1/X.25  -  Diagram  of  states  for  the  transfer  of  restart  packet 
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at  Can  set  up  phase 


Call 

acceoierf 
(see  Non?  ?< 

or 

Call  Fit- 
cut  ;  t 
(Note  4 i 


Nnte  I  This  transition  is  possible  onh  it  the  previous  state  was  DTt  Watnnc  (p2i 

A  tie  ?  Tho  iranMti  t.  is  pussihlt  onl>  it  the  previous  state  wa  PCL  Waittnc  tp3i 

Mott  7  -  This  transition  ftVMake  plaa*  after  timeout  T1 3  • 
h-t*-  L  -  T /.  traL^uticr  ir  politic  or,^  if 

1 1  -  j  re  %  : c  ^ ;  s.  l  ~  1 1  waL  ht  cv  Ky*  ■ 

C  7  l).'t  V,  ,  ;  1  '  1.,  (  ]  3,  . 


Figure  A2.2/X.25  -  Diagrar  cf  states  fc-  the  transfer  of  call  set-ur  ar.i 

oa--  earing  packets  within  the  packet  level  readv  (rl'l 
st  at 
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R*-vt 

reautii 


BfSft 

‘"Ora* 

(see  Not*  i  • 


Not e  f  -  This  transition  ^»r  take  place  after  time-out  T  1  2 


Figure  A2.3/X.25 


Diagram  of  states  for  the  transfer  cf  rest'.  pnsXets 
within  the  data  transfer  (pM  state 
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ANNEX  3 

(to  Recommendation  X.25) 

ACTIONS  TAKEN  BY  THE  DC E  ON  RECEIPT  OF  PACKETS  IN  A  GIVEN  STATE 
OF  THE  PACKET  LEVEL  DTE/DCE  INTERFACE  AS  PERCEIVED  BY  THE  DCE 


TABLE  A3.1/X.25 
Special  cases 

The  number  following  the  #  is  the  diagnostic  code  (see  Annex  5). 


Packet  from  the  DTE 

Any  state 

Any  packet  with  packet 

DIAG 

length  <2  octets 

138 

Any  packet  with  incorrect 

DIAG 

general  format  identifier 

*40 

Any  packet  with  unassigned 

DIAG 

logical  channel 

*36 

Any  packet  with  correct 

SEE  TABLE 

GFI  and  assigned 

A3. 2/X. 25 

logical  channel 

DIAG:  The  DCE  discards  the  received  packet  and,  for  networks 

which  implement  the  diagnostic  packet,  transmits  a  DIAG¬ 
NOSTIC  packet  to  the  DTE  containing  the  indicated  diagnos¬ 
tic  code. 

There  may  be  more  than  one  error  associated  with  a  packet. 
The  network  will  stop  normal  processing  of  a  packet  when 
an  error  is  encountered.  Thus  only  one  diagnostic  code  is 
indicated  in  the  DIAGNOSTIC  packet.  The  order  of  packet 
de-coding  and  checking  on  networks  is  not  standardized. 


i 
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NORMAL: 


DISCARD: 


ERROR: 


Note  1: 


NOTES  TO  TABLE  A3.2/X.25 


The  action  taken  by  the  DCE  follows  the  procedures  as 
defined  in  section  3.  If  a  RESTART  REQUEST  packet  or 
DTE  RESTART  CONFIRMATION  packet  received  in  state  r3 
exceeds  the  maximum  permitted  length,  the  DCE  will 
invoke  the  ERROR  procedure  with  diagnostic  #39  and 
enter  state  r3.  If  a  RESTART  REQUEST  packet  received 
in  state  rl  exceeds  the  maximum  permitted  length,  the 
action  taken  by  the  DCE  is  for  further  study. 

The  DCE  discards  the  received  packet  and  takes  no  sub¬ 
sequent  action  as  a  direct  result  of  receiving  that 
packet . 

The  DCE  discards  the  received  packet  and  indicates  a 
restarting  by  transmitting  to  the  DTE  a  RESTART  INDICA¬ 
TION  packet,  with  the  cause  "Local  procedure  error" 
(diagnostic  per  Table  A3.2/X.25),  If  connected  through 
the  virtual  call,  the  distant  DTE  is  also  informed  of 
the  restarting  by  a  CLEAR  INDICATION  packet,  with  the 
cause  "Remote  procedure  error"  (same  diagnostic) ,  In 
the  case  of  a  permanent  virtual  circuit,  the  distant 
DTE  will  be  informed  by  a  RESET  INDICATION  packet,  with 
the  cause  "Remote  procedure  error"  (same  diagnostic). 

If  a  RESTART  INDICATION  is  issued  as  a  result  of  an 
error  condition  in  state  r2,  the  DCE  should  eventually 
consider  the  DTE /DCE  interface  to  be  in  the  PACKET 
LEVEL  READY  state  (rl). 

There  may  be  more  than  one  error  associated  with  a 
packet.  The  network  will  stop  normal  processing  of  a 
packet  when  an  error  is  encountered.  Thus  only  one 
diagnostic  code  is  associated  with  an  ERROR  indication 
by  the  DCE.  The  order  of  packet  de-coding  and  checking 
on  networks  is  not  standardized. 


Note  2: 


pi  for  logical  channels  assigned  to  virtual  calls;  dl 
for  logical  channels  assigned  to  permanent  virtual  cir¬ 
cuits  and  datagrams. 
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NORMAL: 

DISCARD: 

ERROR: 


Note  1: 

Note  2: 

Note  3: 

Note  4: 


NOTES  TO  TARLE  A3.3/X.25 


The  action  taken  by  the  DCE  follows  the  procedures  as 
defined  in  section  4.  If  the  packet  exceeds  the  max¬ 
imum  permitted  length  the  DCE  will  invoke  the  ERROR 
procedure  with  diagnostic  #39  and  enter  state  p7. 

The  DCE  discards  the  received  packet  and  takes  no  sub¬ 
sequent  action  as  a  direct  result  of  receiving  that 
packet . 

The  DCE  discards  the  received  packet  and  indicates  a 
clearing  by  transmitting  to  the  DTE  a  CLEAR  INDICATION 
packet,  with  the  cause  "Local  procedure  error"  (diag¬ 
nostic  per  Table  A3.3/X.25).  If  connected  through  the 
virtual  call,  the  distant  DTE  is  also  informed  of  the 
clearing  by  a  CLEAR  INDICATION  packet,  with  the  cause 
"Remote  procedure  error"  (same  diagnostic). 

It  is  required  that  in  the  absence  of  an  appropriate 
DTE  response  to  a  CLEAR  INDICATION  packet  Issued  as  a 
result  of  an  error  condition  in  state  p6,  the  DCE 
should  eventually  consider  the  DTE/DCE  interface  to  be 
in  the  READY  state  (pi). 

There  may  be  more  than  one  error  associated  with  a 
packet  (e.g.,  packet  too  long  and  transmitted  in  a 
wrong  state).  The  network  will  stop  processing  of  the 
packet  when  an  error  is  encountered.  Thus  only  one 
diagnostic  code  is  associated  with  an  ERROR  indication 
by  the  DCE.  The  order  of  packet  de-coding  and  checking 
on  networks  is  not  stand ard i zed . 

This  state  does  not  exist  in  the  case  of  an  outgoing 
one-way  logical  channel  (as  perceived  by  the  DTE). 

This  state  does  not  exist  in  the  case  of  an  .ncoming 
one-way  logical  channel  (as  perceived  by  the  DTE). 

(a)  In  the  case  of  an  incoming  one-way  logical  channel 
(as  perceived  by  the  DTE)  the  DCE  will  transmit  a 
CLEAR  INDICATION  with  the  cause  "Local  procedure 
error"  and  diagnostic  #34. 

(b)  The  DCE  will  transmit  a  CLEAR  INDICATION  if  the 
CALL  REQUEST  contains  an  improper  address  format  or 
facility  field;  call  progress  signals  and  diagnos¬ 
tic  codes  are  listed  below: 


1  3-1 


Possible 

Error  Condi t ion  Cause  Diagnostics 

1.  Address  contains  a  non  prD  digit  Local  Procedure  Error  #67, 6P 

2.  Prefix  digit  not  supported  "  "  "  " 

3.  National  address  smaller  than 

national  address  format  permits  "  "  "  " 

4.  National  address  larger  than 

national  address  format  permits  "  "  *  " 

5.  DNIC  less  than  four  digits  "  *  "  " 

6.  Facility  length  larger  than  63  "  "  "  #r>4 

7 .  No  com bi nation  of  facilities 


8. 

could  equal  facility  length 
Facility  length  larger  than 

M 

« 

m 

#64 

9. 

remainder  of  packet 

Facility  values  conflict  (e.g., 
a  particular  combination  not 

m 

M 

m 

#38 

supported) 

m 

II 

m 

#66 

10. 

Facility  code  not  allowed 

Invalid 

Facil  ity 

Request 

#65 

11. 

Facility  value  not  allowed 

If 

m 

« 

#66 

(c)  The  DCE  will  transmit  a  CLEAR  INDICATION  if  the 

remote  DTE  makes  a  procedure  error,  either  for  one 
of  the  above  reasons  associated  with  its  call 
acceptance,  or  because  of  an  expired  timeout  (diag¬ 
nostic  149). 

Note  5:  In  the  case  of  an  permanent  virtual  circuit,  the  DCE 

discards  the  received  packet  and  indicates  a  reset  by 
transmitting  to  the  DTE  a  RESET  INDICATION  packet,  with 
the  cause  "Local  procedure  error"  (diagnostic  135), 

The  distant  DTE  is  also  informed  of  the  reset  by  a 
RESET  INDICATION  packet,  with  the  cause  "Remote  pro¬ 
cedure  error"  (same  diagnostic). 

In  the  case  of  a  datagram  logical  channel,  the  DCE  dis¬ 
cards  the  received  packet  and  indicates  a  reset  by 
transmitting  to  the  DTE  a  RESET  INDICATION  packet,  with 
the  cause  "Local  procedure  error". 

Note  5:  The  ERROR  procedure  will  be  invoked  by  the  DCE  if  the 

CALL  ACCEPTED  packet  contains  an  improper  address  for¬ 
mat  or  facility  field.  Examples  are  similar  to  those 
in  Note  4  point  (b)  above. 

Note  7:  The  presence  of  the  Fast  Select  facility,  indicating 

restriction  on  response  in  an  INCOMING  CALL  packet 
prohibits  the  DTE  from  sending  a  CALL  ACCEPTED  packet. 
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NORMAL: 


DISCARD: 


ERROR: 


Note  1: 


Note  2: 


NOTES  TO  TABLE  A3.4/X.25 


The  action  taken  by  the  DCE  follows  the  procedures 
as  defined  in  sections  4  and  5.  If  the  packet  exceeds 
the  maximum  permitted  length,  the  DCE  will  invoke  the 
ERROR  procedure  using  diagnostic  code  139  and  enter 
state  d3. 

The  DCE  discards  the  received  packet  and  takes 
no  subsequent  action  as  a  direct  result  of  receiving 
that  packet. 

The  DCE  discards  the  received  packet  and  indicates 
a  reset  by  transmitting  to  the  DTE  a  RESET  INDICATION 
packet,  with  the  cause  "Local  procedure  error" 
(diagnostic  per  Table  A3.4/X.25).  For  virtual  calls  and 
permanent  virtual  circuits,  the  distant  DTE  is  also 
informed  of  the  reset  by  a  RESET  INDICATION  packet, 
with  the  cause  "Remote  procedure  error"  (same 
diagnostic) . 

If  a  RESET  INDICATION  is  issued  as  a  result  of  an 
error  condition  in  state  d2  for  permanent  virtual 
circuits  and  datagram  logical  channels,  the  DCE 
should  eventually  consider  the  DTE/DCE  interface 
to  be  in  the  FLOW  CONTROL  READY  state  (dl)  In 
this  case,  the  action  to  be  taken  on  a  virtual 
call  is  for  further  study. 


There  may  be  more  than  one  error  associated  with  a 
packet  (e.g.,  Invalid  P(S)  and  Invalid  P(R)).  The 
network  will  stop  processing  of  the  packet  when  an 
error  is  encountered.  Thus  only  one  diagnostic  code 
is  associated  with  an  ERROR  indication  by  the  DCE. 
The  order  of  packet  de-coding  and  checking  on 
networks  is  not  standardized. 

The  DCE  will  consider  the  receipt  of  a  DTE  INTERRUPT 
CONFIRMATION  packet  which  does  not  correspond  to  a 
yet  unconfirmed  DCE  INTERRUPT  packet  as  an  error 
and  will  reset  the  virtual  call  or  permanent  circuit 
(diagnostic  943).  The  DCE  will  either  discard  or 
consider  as  an  error  a  DTE  INTERRUPT  packet  received 
before  a  previous  DTE  INTERRUPT  packet  has  been 
confirmed  (diagnostic  944). 

If  the  P  (S )  or  P  (R )  received  is  not  valid,  the  DCE 
will  invoke  the  ERROR  procedure  with  diagnostics 
91  and  92  respectively,  and  enter  state  d3. 
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ANNEX  4 

(to  Recommendation  X.25) 

PACKET  LEVEL  DCE  TINE-OUTS  AND  DTE  TIME-LIMITS 


DCE  time-outs 


Under  certain  circumstances  this  Recommendation  requires  the  DTE 
to  respond  to  a  packet  iss'ued  from  the  DCE  within  a  stated  max¬ 
imum  time. 

Table  A4.1/X.25  covers  these  circumstances  and  the  actions  that 
the  DCE  will  initiate  upon  the  expiration  of  that  maximum  time. 


PTE  time-limits 


Under  certain  circumstances,  this  Recommendation  requires  the  DCE 
to  respond  to  a  packet  from  the  DTE  within  a  stated  maximum  time. 
Table  A4.2/X.25  gives  these  maximum  times.  The  actual  DCE 
response  times  should  be  well  within  the  specified  time-limits. 
The  rare  situation  where  a  time-limit  is  exceeded  should  only 
occur  when  there  is  a  fault  condition. 

To  facilitate  recovery  from  such  fault  conditions,  the  DTE  may 
incorporate  timers.  The  time-limits  given  in  Table  A4.2/X.25  are 
the  lower  limits  of  the  times  a  DTE  should  allow  for  proper 
operation.  A  time-limit  longer  than  the  values  shown  may  be 
used.  Suggestions  on  possible  DTE  actions  upon  expiration  of  the 
time-limits  are  given  in  Table  A4.2/X.25. 

Note :  A  DTE  may  use  a  timer  shorter  than  the  value  given  for  T21 
in  Table  A4.2/X.25.  This  may  be  appropriate  when  the  DTE 
knows  the  normal  response  time  of  the  called  DTE  to  an 
Incoming  call.  In  this  case,  the  timer  should  account  for 
the  normal  maximum  response  time  of  the  called  DTE  and  the 
estimated  maximum  call  set-up  time. 


TABLE  A4.1/X.25 
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a  clear  state  (e.g.,  the  may  issue  a  Diagnostic 

indication  clear  confirmation  packet  (Note  ,4  ) 

or  clear  request 
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Note  1 


Note  2 


Note  3 


Note  4 


NOTES  TO  TABLE  A4.1/X.25 


The  following  Notes  2,  3  and  4  describe  alternative  DCE 
actions  on  timer  expiration.  It  is  envisaged  that  all 
networks  will  eventually  conform  to  Table  A4.1/X.25, 
however  for  an  interim  period  the  following  procedures 
may  be  used. 

No  values  have  yet  been  assigned  to  the  time-out  t  and 
the  maximum  number  of  retries  n  applying  to  the  follow¬ 
ing  notes,  however  it  should  be  noted  that  some  Adminis¬ 
trations  may  use  the  combination  t-infinite,  n-zero 
(i.e.,  no  retries  and  no  recovery  action)  or  t-finite, 
n-zero  (i.e.,  no  retries  with  recovery  action  on  timer 
expiration).  The  values  of  n  and  t  will  not  necessarily 
be  the  same  for  the  clear,  reset  and  restart  procedures. 

Alternatively,  the  DCE  will  retransmit  the  RESTART  INDI¬ 
CATION  at  regular  intervals  of  t  until  a  DTE  RESTART 
CONFIRMATION  is  received  or  a  restart  collision  occurs 
or  a  period  (n  +  1 ) t  elapses  since  the  first  transmis¬ 
sion  of  the  RESTART  INDICATION.  If  the  restart  pro¬ 
cedure  is  not  completed  within  the  time-out  period, 
appropriate  recovery  action  will  be  taken. 

Alternatively,  the  DCE  will  transmit  the  RESET  INDICA¬ 
TION  at  regular  intervals  of  t  until  a  DTE  RESET  CONFIR¬ 
MATION  is  received  or  a  reset  collision  occurs  or  a 
period  (n  ♦  l)t  elapses  since  the  first  transmission  of 
the  RESET  INDICATION.  If  the  reset  procedure  is  not 
completed  within  the  time-out  period  the  DCE  will 
either: 

11  clear  the  virtual  call  with  an  indication  of  pro¬ 
cedure  error  ,  or 

ii)  in  the  case  of  permanent  virtual  circuit  forward  a 
RESET  INDICATION  (remote  procedure  error)  to  tne 
local  DTE  at  regular  intervals  t  until  a  DTE  RESET 
CONFIRMATION  is  received  or  a  reset  collision 
occurs. 

Alternatively,  the  DCE  will  retransmit  a  CLEAR  INDICA¬ 
TION  at  regular  intervals  of  t  until  a  DTE  CLEAR  CONFIR¬ 
MATION  is  received  or  a  clear  collision  occurs  or  a 
period  (n  ♦  l)t  elapses  since  the  first  retransmission 
of  the  CLEAR  INDICATION.  If  the  clear  procedure  is  not 
completed  within  the  time-out  period,  appropriate 
recovery  action  will  be  initiated.  The  nature  of  the 
recovery  action  is  for  further  study. 


TABLE  A4.2/X.25 
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Note  1:  After  unsuccessful  retries,  recovery  decisions  should  be  taken  at  higher  levels. 

Note  2:  After  unsuccessful  retries,  the  logical  channel  should  be  considered  out-c f-order .  The  restart  trocc 
should  only  be  invoked  for  recovery  if  reinitialization  of  all  logical  channels  is  acceptable. 
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ANNEX  5 

(to  Recommendation  X.25) 

CODING  OF  X.25  NETWORK  GENERATED  DIAGNOSTIC  FIELDS  IN  CLEAR, 

RESET  AND  RESTART  INDICATION  AND  DIAGNOSTIC  PACKETS  (Notes  1,  2  and  3) 


Diaqnost ics 

No  Additional  Information 

Inval id  P (S ) 

Invalid  P(R) 

R 

0 

0 

0 

0 

7 

0 

0 

0 

0 

6 

0 

0 

0 

• 

0 

Bits 

5  4 

0  0 

0  0 

0  0 

0 

n  i 

3 

n 

0 

n 

0 

1 

2 

0 

0 

1 

1 

1 

0 

1 

0 

1 

Decimal 

P 

1 

2 

15 

Packet  type  invalid 

0 

0 

n 

l 

n 

0 

0 

0 

16 

for  state  rl 

0 

0 

n 

l 

0 

0 

0 

1 

17 

for  state  r2 

0 

0 

0 

l 

0 

0 

1 

0 

IB 

for  state  r3 

0 

0 

0 

l 

0 

n 

1 

1 

19 

for  state  pi 

0 

0 

0 

l 

0 

l 

n 

0 

2P 

for  state  p2 

0 

0 

0 

l 

n 

l 

0 

1 

21 

for  state  p3 

0 

0 

0 

l 

0 

l 

1 

0 

22 

for  state  p4 

0 

0 

0 

l 

0 

l 

1 

1 

23 

for  state  p5 

0 

0 

0 

l 

i 

n 

n 

p 

24 

for  state  p6 

0 

0 

0 

l 

l 

0 

0 

1 

25 

for  state  p7 

0 

0 

n 

l 

l 

0 

l 

n 

26 

for  state  dl 

0 

0 

n 

l 

l 

0 

l 

l 

27 

for  state  d2 

0 

0 

0 

l 

l 

1 

0 

n 

28 

for  state  d3 

0 

0 

0 

l 

l 

1 

0 

l 

29 

0 

n 

w 

0 

l 

l 

1 

1 

l 

31 

Packet  not  allowed 

0 

0 

1 

0 

0 

0 

0 

0 

32 

unidentifiable  packet 

0 

0 

1 

0 

0 

0 

0 

l 

33 

call  on  one  way 
logical  channel 

0 

0 

1 

0 

0 

0 

1 

0 

34 

invalid  packet  type  on  a 
permanent  virtual  circuit 

0 

0 

1 

0 

0 

0 

1 

1 

35 

packet  on  unassigned 
logical  channel 

0 

0 

1 

0 

0 

1 

0 

0 

36 

REJECT  not  subscribed  to 

0 

D 

1 

0 

0 

1 

0 

1 

37 

packet  too  short 

0 

0 

1 

0 

0 

1 

1 

p 

38 

packet  too  long 

0 

0 

1 

0 

0 

1 

1 

1 

39 

invalid  general  format 
ident i f i er 

n 

0 

1 

0 

1 

0 

0 

p 

40 

restart  with  nonzero  in 
bits  1-4,9-16 

n 

0 

1 

0 

1 

0 

0 

1 

41 

packet  type  not  compatible 
with  f ac i  1  ity 

0 

n 

1 

P 

1 

0 

1 

p 

42 

unauthorized  interrupt 
confirmation 

0 

0 

1 

n 

1 

0 

1 

1 

43 

unauthorized  interrupt 

0 

0 

1 

0 

1 

1 

p 

0 

44 

•  * 


0 


-  14  2  - 


0 

n 

l 

p 

1 

1 

3 

3 

4 

Timer  expired 

P 

n 

i 

1 

p 

0 

P 

P 

A 

for  INCOMING  CALL 

0 

0 

l 

1 

p 

p 

0 

3 

4 

for  CLEAR  INDICATION 

n 

0 

i 

1 

p 

p 

3 

0 

5 

for  RESET  INDICATION 

n 

0 

l 

1 

0 

0 

3 

3 

p 

for  RESTART  INDICATION 

p 

P 

l 

1 

0 

3 

P 

p 

c 

4 

•  a 

p 

n 

1 

3 

1 

3 

3 

3 

r. 

Call  setup  problem 

0 

i 

0 

0 

0 

n 

P 

n 

R 

facility  code  not  allowed 

0 

i 

0 

p 

0 

0 

0 

l 

facility  parameter  not 

all  owed 

0 

l 

0 

0 

n 

0 

1 

0 

R 

invalid  called  address 

0 

l 

0 

0 

n 

n 

1 

l 

R 

invalid  calling  address 

0 

i 

n 

0 

0 

i 

P 

0 

6 

0 

i 

0 

0 

i 

l 

1 

l 

7 

Not  assiqned 

0 

l 

0 

1 

0 

p 

0 

0 

8 

< 

• 

a 

0 

l 

0 

1 

1 

l 

1 

l 

o 

Not  assigned 

0 

l 

1 

0 

t  1 

0 

)  0 

0 

n 

0 

p 

0 

l 

1 

n 

1 

l 

l 

l 

11 

Not  assigned 

0 

1 

1 

l 

0 

0 

0 

0 

n 

i 

»  • 

• 

0 

i 

1 

l 

1 

1 

i 

1 

12 

Reserved  for  network 

1 

n 

0 

0 

0 

0 

0 

0 

1? 

specific  diagnostic 

< 

1  < 

>  1 

information 

1 

l 

1 

1 

1 

1 

1 

1 

21 

Note  1:  Not  all  diagnostic  codes  need  apply  to  a  specific  net¬ 
work,  but  those  used  are  as  coded  in  the  table. 


Note  2:  A  given  diagnostic  need  not  apply  to  all  packet  types 

(i.e.,  RESET  INDICATION,  CLEAR  INDICATION,  RESTART  INDI¬ 
CATION  and  DIAGNOSTIC  packets)  . 


Note  3:  The  first  diagnostic  in  each  grouping  is  a  generic  diag¬ 
nostic  and  can  be  used  in  place  of  the  more  specific 
diagnostics  within  the  grouping.  The  decimal  0  diagnos¬ 
tic  code  can  be  used  in  situations  where  no  additional 
information  is  available. 
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CALL  PROGRESS  SIGNALS  FOR  X.25 
FROM  CCITT  RECOMMENDATION  X.96  (1980) 


APPENDIX  B 


Descriptions  of  Call  Progress  Signals  (Cause  Codes) 

The  call  progress  signals  and  the  related  circumstances  giving  rise  to  them 
are  defined  in  Table  1. 

The  significance  of  categories  indicates  broadly  the  type  of  action  expected 
of  the  DIE  receiving  the  signal: 

Category 

A  requested  action  confirmed  by  network. 

B  call  cleared  because  the  procedure  is  conplete. 

Cl  and  C2  call  cleared.  The  calling  DTE  should  call  again  soon: 

the  next  attempt  may  be  successful.  However,  after  a 
number  of  unsuccessful  call  attempts  with  the  same 
response  the  cause  could  be  assumed  to  be  in  Category 
Dl  or  D2.  The  interval  between  successive  attempts , 
and  the  maximum  number  of  attempts,  will  depend  on  a 
number  of  circumstances  including: 

-  nature  of  the  call  progress  signal 

-  users '  traffic  pattern 

-  tariffs 

-  possible  regulations  by  the  network  provider, 
or 

reset.  The  DTE  may  continue  to  transmit  data  recognizing 
that  data  loss  may  have  occurred. 


-2- 


D1  and  D2  call  cleared.  The  calling  DIE  should  take  other  action 
to  clarify  when  the  call  attempt  might  be  successful, 
or 

reset  (for  permanent  virtual  circuit  and  datagram 
logical  channels  only) .  The  DIE  should  cease  data 
transmission  and  take  other  action  as  appropriate. 

Cl  and  Dl  due  to  subscriber  condition. 

C2  and  D2  due  to  network  condition. 

The  sequence  of  call  progress  signals  in  the  table  implies,  for  Categories  C 
and  D,  the  order  of  call  set-up  processing  by  the  network.  In  general  the 
DIE  can  asstxne,  on  receiving  a  call  progress  signal,  that  no  condition  higher 
up  the  table  is  present.  Network  congestion  is  an  exception  to  thi'  general 
rule.  The  actual  coding  of  call  progress  signals  does  not  necessarily  reflect 
this  sequence. 

User 8  and  DIE  manufacturers  are  warned  to  make  due  allowance  to  possible  later 
extensions  to  this  table  by  providing  appropriate  fall -back  routines  for 
unexpected  signals. 

For  datagram  service,  which  does  not  embrace  the  concept  of  a  call,  the 
term  "call"  should  be  interpreted  as  "datagram",  "calling"  as  "source", 
"called"  as  "destination",  "cleared"  as  "not  delivered". 


Table  1 


Definition 


Delivery  confirmation 


The  datagram  has  been  accepted  by 
the  destination  DIE. 


local  procedure  error 


A  procedure  error  caused  by  the  DIE 
is  detected  by  the  DCE  at  the  local 
DIE/DCE  interface. 


Network  congestion 


A  condition  exists  in  the  network  such 


1)  tenporary  network  congestion 

2)  tenporary  fault  condition  within 
the  network,  including  procedure 
error  within  a  network  or  an 
international  link. 


Invalid  facility  request 


RFQA  Out  of  Order 


Not  obtainable 


A  facility  requested  by  the  calling 
DIE  is  detected  as  invalid  by  the 
DCE  at  the  local  DIE/DCE  interface. 
Possible  reasons  include: 

-  request  for  a  facility  which  has 
not  been  subscribed  to  by  the  DIE; 

-  request  for  a  facility  which  is 
not  available  in  the  local  network; 

-  request  for  a  facility  which  has 
not  been  recognized  as  valid  by  the 
local  DCE. 


The  RPQA  nominated  by  the  calling  DIE 
is  unable  to  forward  the  call. 


The  called  DTE  address  is  out  of  the 
lumbering  plan  or  not  assigned  to 
any  DIE. 


Call  Progress  Signal 


Definition 


Category 


Access  barred 

The  calling  DIE  is  not  permitted 
the  connection  to  the  called  DIE. 

Possible  reasons  include: 

-  unauthorized  access  between  the 
calling  DTE  and  the  called  DTE; 

-  inconpatible  closed  user  group. 

— 

D1 

1 

Reverse  charging 
acceptance  not 

subscribed 

The  called  DIE  has  not  subscribed  to 

the  reverse  charging  acceptance 
facility. 

D1 

Fast  select  acceptance 

not  subscribed 

. 

The  called  DTE  has  not  subscribed 
to  the  fast  select  acceptance 
facility . 

. 

D1 

-  - 

Incompatible  destination 

The  ranote  DIE/DCE  interface  or 

the  transit  network  does  not 
support  a  function  or  facility 
requested  (e.g. ,  the  datagram 

service) . 

.... 

Dl 

Out  of  order 

The  remote  number  is  out  of  order. 

Possible  reasons  include: 

-  DIE  is  Uncontrolled  Not  Ready; 

-  DCE  Power  Off ; 

-  Network  fault  in  the  local  loop; 

-  X. 25  Level  1  not  functioning; 

-  X.25  Level  2  not  in  operation. 

D1 

or 

D2 

Number  busy 

The  called  DIE  is  detected  by  the  DCE 
as  engaged  on  other  call(s) ,  and 
therefore  as  not  being  able  to  accept 
the  incaning  call.  (In  the  case  of 
the  datagram  service,  the  queue  at  the 
destination  DCE  is  full.) 

Cl 

Call  Progress  Signal 


Definition 


Category 


Remote  procedure  error 

A  procedure  error  caused  by  the 
remote  DIE  is  detected  by  the  DCE 
at  the  remote  DIE/DCE  interface. 

D1 

Network  operational 

Network  is  ready  to  resvzne  normal 
operation  after  a  temporary  failure 
or  congestion. 

Cl 

Remote  DTE  operational 

Remote  DIE/DCE  interface  is  ready 

Cl 

to  resume  normal  operation  after 

or 

a  temporary  failure  or  out  of  order 
condition  (e.g.,  restart  at  the 
remote  DIE/DCE  interface),  loss  of 
data  may  have  occurred. 

D1 

DIE  originated 

The  remote  DTE  has  initiated  a  clear, 

B  or 

reset  or  restart  procedure. 

D1 

appendix  c 


INTERIM  FEDERAL  STANDARD  1041 
INTERNATIONAL  USER  SERVICES  AND  FACILITIES 
FROM  CCITT  RECOMMENDATION  X.2  (1980) 


Facilities  of  packet  switched  data  networks 


User  Facility 

VC 

PVC 

DG 

1.  Optional  user  facilities  assigned 

for  an  agreed  contractual  period 

1.1  Extended  packet  sequence  numbering 

(modulo  128) 

A 

A 

A 

1.2  Non-standard  default  window  sizes 

A 

A 

A 

1.3  Non-standard  default  packet  sizes 

16,  32,  64,  266,  512,  1024 

A 

A 

- 

1.4  Default  throughput  clear 

assignment 

A 

A 

A 

1.5  Flow  control  parameter  negotiation 

E 

- 

- 

1.6  Tnroughput  class  negotiation 

E 

- 

- 

1.7  Packet  re-transmission 

A 

A 

A 

1.8  Incoming  rails  barred 

E 

- 

E 

1.9  Outgoing  calls  barred 

E 

- 

E 

1.10  One-way  logical  channel  outgoing 

E 

- 

A 

1.11  One-way  logical  channel  incoming 

A 

- 

A 

1.12  Closed  user  group 

E 

- 

E 

1.13  Closed  user  group  with  outgoing 

access 

A 

- 

A 

1.14  Closed  user  group  with  incoming 

access 

A 

- 

A 

1.15  Incoming  calls  barred  within  a 

closed  user  group 

A 

- 

A 

1.16  Outgoing  calls  barred  within  a 

closed  user  group 

A 

- 

A 

1.17  Bilateral  closed  user  group 

A 

- 

A 

1.16  Bilateral  closed  user  group  with 

outgoing  access 

A 

- 

A 

1.19  Reverse  charging  acceptance 

A 

A 

1.20  Fast  select  acceptance 

A 

- 

- 

1.21  Datagram  queue  length  selection 

- 

- 

A 

1.22  Datagram  service  signal  logical 

channe 1 

- 

- 

A 

1.23  Datagram  non-delivery  indication 

- 

- 

E 

1.24  Datagram  delivery  confirmation 

- 

- 

E 

1.25  Multiple  circuits  to  the  same  DTE 

A 

A 

A 

1.26  Charging  information 

FS 

- 

FS 

1.27  Oirect  call 

FS 

- 

FS 

1.28  Multiple  terminals  with  the  same 

data  number 

FS 

- 

FS 

1.29  On-line  facility  registration 

A 

- 

A 

1.30  D-bit  modification 

A 

A 

- 

2. 

Optional  user  facilities  requested 
by  the  DTE  on  a  per  call  basis 

2.  1 

Closed  user  group  selection 

E 

* 

E 

2.2 

Bilateral  closed  user  group 
selection 

A 

A 

2.3 

Reverse  charging 

A 

- 

A 

2.4 

RPOA  selection 

A 

- 

A 

2.5 

Flow  control  parameter 
negotiation 

E 

_ 

2.6 

Fast  select 

A 

- 

- 

2.7 

Throughput  class  negotiation 

E 

- 

- 

2.8 

Abbreviated  address  calling 

FS 

- 

A 

2.y 

Datagram  non-del  i very  indication 

- 

- 

E 

2. 10 

Datagram  delivery  confirmation 

- 

- 

E 

2.  1  1 

Multi-address  calling 

A 

- 

FS 

2.12 

Charging  information 

FS 

- 

FS 

Legend  for  Table  1/X.2: 

E  =  An  essential  user  service  or  facility  to  be  made  available 
international ly. 

A  =  An  additional  user  service  or  facility  which  may  be  available  in 
certain  data  networks  and  may  also  be  available  internationally. 

FS  =  For  further  study. 

=  Not  applicable. 

DG  =  Applicable  when  the  datagram  services  being  used. 

VC  =  Applicable  when  the  virtual  call  service  is  being  used. 

PVC  =  Applicable  when  the  permanent  virtual  circuit  service  is  being 

used. 


